Skip to end of metadata
Go to start of metadata


Not all ccTLD (Country Code Top Level Domains) or gTLD (generic Top Level Domains) are DNSSEC signed (Status 2/2011). Domains below these unsigned TLDs are not in the 'Chain of Trust', even if they are DNSSEC signed, they cannot be validated.


DNS Zones are signed but cannot be validated from the DNS root down.


Internet Software Consortium (ISC) runs a service called DLV (DNSSEC Lookaside Validation, RFC 5074). The DLV contains many trust anchors for DNS domains that are signed, but cannot be validated from the root zone down. 

Instead of maintaining each trust-anchor in each validating DNS Servers configuration file, the DLV registry will contain the trust-anchors for the zones and the local validating DNS Server only needs to have one trust-anchor for the DLV zone.

A DLV registry functions like a database of trusted keys.  In practice, it's a zone containing DLV records, which are functionally similar to DS records. Only one trust anchor is needed in the resolver config, to validate the DLV zone. The DLV records then validate other zones' public keys, just like DS records. Multiple DLV registries are possible, but there's one main one: BIND 9.7+ and Unbound 1.4.1 ship with a trusted initial key for this DLV registry.

Because ISCs DLV zone is below "" and "org.", which are both signed, the trusted key can also be fetched by a validated DNS query (the resolving DNS Server must have DNSSEC and the trust-anchor for the root-zone configured:
dig dnskey +dnssec

; <<>> DiG 9.7.3 <<>> dnskey +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44744
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096
;                   IN      DNSKEY

;; ANSWER SECTION:            2538    IN      DNSKEY  257 3 5 BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh            2538    IN      DNSKEY  256 3 5 BEAAAAOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAaGPT+Q0kpiN+7 GviFh+nIazoB8e2Yv7mupgqkmIjObdcbGstYpUltdECdNpNmBvASKB9S BdtGeRvXXpORi3Qyxb9kHGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBF tCibp/mkhw==            2538    IN      RRSIG   DNSKEY 5 3 7200 20110320201503 20110218201503 19297 PFaw5SQ0GV4GGyIYoQ75iGszAw4WC77Hl1Z+Eh2fe6EWiXGtP9rAQTTw Z6UOb38cMHMnu1Wj/5VYL5MBmbHQSMhQPGs82Y/Xys8KrHPBDeBtU0Pf gqr8vmR+MmEwLOW9BEkiEKk4+vpLpwBDhF8qMKGDQOwu8urnEw8oYPXa HPOHV7WgrOceza45qW9fsGZ4LrhKtXaWoQwjB7nnr33Y2jW7u6TxQfzN sw9jVm+HZjb1D4dy5yXCTOGNoZTChLwQjOvek48mxPiblQ9fXrWHiLhQ vQrqGaKUDkclLIBHk5Fql2sVV4T5YQisQ9RA2tMusaH+u/m6lTtH0Fm3 jgENQg==            2538    IN      RRSIG   DNSKEY 5 3 7200 20110320201503 20110218201503 64263 OH6+dhrjb9H87EreA0au8vy0GFVQAqUKnRweZGCSfi/XESDQvtvr6TUv pRQl0sKPbS4YzH5f2lOo/laKfFg5YmXW9Ehv64r/J1Q2UQyWCFeGNSey H26GAV+jCAnjqKNlXQA5LbIbmGcj4GfB+EvUEDmWMYF4D6rzm677SwjM v+M=

;; Query time: 181 msec
;; WHEN: Sat Feb 19 11:19:51 2011
;; MSG SIZE  rcvd: 936              

Check for the "AD" flag in the DNS query (AD = Authenticated Data).

For Unbound, we need the DNSKEY record (the public key) for the Key Signing Key (KSK) of the DLV Zone. A KSK DNSKEY Record has the secure entry point flag set in the flags field, so the first field has the value "257".

We copy the line containing the KSK DNSKEY record into a file called "", and add the line

dlv-anchor-file: ""

to the Unbound configuration file "unbound.conf".

A validating Resolver with DLV configured will first...
  • look if there are manual trust-anchors in the configuration
  • if that is not available, it will try to get the trust from the delegation tree (DS record in the parent zone)
  • if that is also not available, it will try to look up the trust-anchor in the DLV zone(s) ...
  • If there is more than one DLV zone configured that will match the target name (overlapping DLV domains)
    • The resolver will first try the DLV zone with the most matching labels (most specific domain), then trying the others with shorter matching labels (DLV for “”, will 1st look in DLV for “company.example”, then in DLV Zone for “example” and then for “.”)
  • The same behavior is used for finding DLV trust anchors in a DLV zone
Because DNSSEC validation using the parent has priority over DLV, once the parent of the zone is signed, validation is done using the DS records in the parent and not using DLV.

Information about the ISC DLV registry can be found at