19 Feb 2011

Configure DLV (DNSSEC Lookaside Validation) for Unbound

Not all ccTLD (Country Code Top Level Domains) ot 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.

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: dlv.isc.org. BIND 9.7+ and Unbound 1.4.1 ship with a trusted initial key for this DLV registry.

Because ISCs DLV zone is below "isc.org." 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 dlv.isc.org. dnskey +dnssec +multi

; <<>> DiG 9.8.0rc1 <<>> dlv.isc.org. dnskey +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50425
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org.       IN DNSKEY

;; ANSWER SECTION:
dlv.isc.org.        676 IN DNSKEY 256 3 5 (
                BEAAAAOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAa
                GPT+Q0kpiN+7GviFh+nIazoB8e2Yv7mupgqkmIjObdcb
                GstYpUltdECdNpNmBvASKB9SBdtGeRvXXpORi3Qyxb9k
                HGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBFtCibp/mk
                hw==
                ) ; key id = 64263
dlv.isc.org.        676 IN DNSKEY 257 3 5 (
                BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn
                4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW
                58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6B
                D4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/o
                Q+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte
                /URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw
                /mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+
                al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh
                ) ; key id = 19297
dlv.isc.org.        676 IN RRSIG DNSKEY 5 3 7200 20110321090006 (
                20110219090006 19297 dlv.isc.org.
                MXYbzeUU+x2F1sx/5gXUFJI6np/0svU5emAaQunG5lCO
                S0Hcb8QoLYaSMxy+2R38smaH7EVTPbst8gYX7t1NousC
                yb02kDHOei3qioRN/LyWd7qeJPCneu/MO1xjul5PCqmV
                yUlnj/5KRj3elYsdo5x5DE2D+s8ivnZBNXzAZU0EQ+pi
                tt4DFVNMNqEmqwM/q/GMZ2px3VlHKMoelxpgXHK+WeDI
                /19UwzuUJ6ykCa+PS9biVsCQTr+5jHnUKU/dNH7lDmfS
                rdGnaZrDu+T2RoNWxM6FjqjVmJhFss/PbFgYj1xbJbjj
                XX0ZBGqUEHUBfe6wOnx2jRqSvTt/RnOJTw== )
dlv.isc.org.        676 IN RRSIG DNSKEY 5 3 7200 20110321090006 (
                20110219090006 64263 dlv.isc.org.
                EnX0YVax8Aosb51CW13V0+V1PrvLzpe19r5PsTje7le7
                N+woHkDmMDy/yPnGDbGE1Vu0Z8sh2RenhAYkUMEpboV2
                jXMIhiO08FQzcvUgiZuAuDkxtYLgkHCTKBXBRKJtS0fC
                QYEFA2NTCYyPviEtirXpuPg9u2BoAYCdlizUaKk= )

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 19 13:33:01 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 "dlv.isc.org.key", and add the line

dlv-anchor-file: "dlv.isc.org.key"

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 ?europe.company.example?, 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 https://dlv.isc.org/