When someone types a URL into a web browser, it quietly makes a DNS lookup on their behalf. A query is transmitted, usually in the clear, to a recursive resolver. This recursive resolver asks appropriate authoritative servers for the answer, and follows a chain from the root domain to the one that contains the name being looked up.
In the current DNS world, very little of this data is secured, and thus it is not difficult to spoof. DNS was never intended to be private, but there is no way to know that the address your browser received is really the address it should be. With all the DNS spoofing attacks recently, DNSSEC has come into the foreground as a method to ensure that the address is the correct one, and that no malicious spoofing is taking place.
Unfortunately, you can't use standard DNSSEC unless all of a domain's parents in the hierarchy are also signed. The root domain is not signed, nor are many of the big “top level domains” such as com, net, and info. DLV (DNSSEC Lookaside Validation) was invented as a way to use DNSSEC when parent zones are not yet signed.
To use ISC's DLV registry, you need to have some intermediate knowledge of how DNS works, and at least a vague understanding of how DNSSEC works. The remainder of this document describes specific technologies used in (and problems with) DNSSEC deployment.
DNSSEC key records are placed into a zone in DNSKEY records. These records describe the public portion of the key and make it available for a resolver to use. There are two types of keys used in DNSSEC to secure your zone.
The first type of key is the “Zone Signing Key,” referred to as a ZSK. The ZSK's duty is to sign your zone's records. This key can be changed frequently, with certain restrictions. These keys should be short enough so as not to bog down resolvers, which must use this key to verify every record retrieved from your servers.
The second type of key is the “Key Signing Key,” or KSK. The purpose of this key is to connect your zone's parent to yours. KSK changes need to be coordinated with your zone's parent zone, and so a KSK might be changed much less frequently than a ZSK. Because they are changed less frequently, they are usually longer than a ZSK. A KSK only signs the set of DNSKEYs used, both ZSK and KSK.
While both types of keys must be present at the top of your zone for DNSSEC to function, only the KSK needs to be “published” to outside agencies. The ZSK is only used within your zone.
Keys of all types are generally quite long (many hundreds of characters), and so a shorter, more compact form of a reference to a key is used as a stand-in, where possible. These shorter items are not keys, they are references to keys. They are called “hashes” and are distributed in two types of DNS records, the DS record and the DLV record. If your zone's parent is signed (for instance, example.com's parent would be .com), then the parent can provide, along with the NS records that form the naming chain, a DS record. This is the intended, designed-in chaining of trust for DNSSEC. Whenever you can use this form of trust relationship, you would do well to use it.
However, few of the top-level zones (.com, .net, .info, and the root zone) are signed. It is therefore impossible using standard DNSSEC to get a trusted path from the root zone (whose name is “.”) all the way to your domain. This is why DLV exists: it's an alternate means of constructing a trusted path to a root-like zone. In DNSSEC terms, DLV connects “islands of trust.”
DLV records are a way to secure your zone's published data even when your parent, or its parent, is not signed. It uses the DLV DNS record, which is nearly identical to the DS records mentioned above. When a DNS resolver looks for data, it makes a second query in a special zone to see if there are DLV records present for it. If there are DLV records, they provide the trust the resolver can use to enable DNSSEC validation for your records.
DNSSEC-aware resolvers have the ability to specify “trust anchors”. These allow a recursive server to bypass the normal “start at the root” trust path, by explicitly trusting a specific key for a specific non-root zone. Since there are millions of zones in use today, this method would require an administrator to add a trust anchor for every zone whose parent is not yet signed.
The per-zone trust anchor scheme is difficult to manually maintain in a large scale. Instead, an administrator who is using DLV can add a single trusted key for “dlv.isc.org.” DLV-aware resolvers will then use the data contained in that zone all trust anchor lookups, eliminating the need for manual additions.