Skip to end of metadata
Go to start of metadata

Symptom:

the DNS lookup tool "dig" has a very useful feature to trace the DNS delegation from the root-DNS down to the requested domain name. Such a trace looks like this:
% dig menandmice.com +trace 

; <<>> DiG 9.7.1-P2 <<>> menandmice.com +trace
;; global options: +cmd
.            7602    IN    NS    k.root-servers.net.
.            7602    IN    NS    e.root-servers.net.
.            7602    IN    NS    l.root-servers.net.
.            7602    IN    NS    c.root-servers.net.
.            7602    IN    NS    d.root-servers.net.
.            7602    IN    NS    g.root-servers.net.
.            7602    IN    NS    b.root-servers.net.
.            7602    IN    NS    j.root-servers.net.
.            7602    IN    NS    m.root-servers.net.
.            7602    IN    NS    a.root-servers.net.
.            7602    IN    NS    h.root-servers.net.
.            7602    IN    NS    i.root-servers.net.
.            7602    IN    NS    f.root-servers.net.
;; Received 304 bytes from 192.168.1.240#53(192.168.1.240) in 15 ms

com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 186 ms

menandmice.com.        172800    IN    NS    dns1.menandmice.com.
menandmice.com.        172800    IN    NS    ns0.c.is.
menandmice.com.        172800    IN    NS    ns1.c.is.
menandmice.com.        172800    IN    NS    ns2.c.is.
;; Received 125 bytes from 192.41.162.30#53(l.gtld-servers.net) in 121 ms

menandmice.com.        120    IN    A    64.40.104.112
menandmice.com.        86400    IN    NS    dns1.menandmice.com.
menandmice.com.        86400    IN    NS    ns0.c.is.
menandmice.com.        86400    IN    NS    ns2.c.is.
menandmice.com.        86400    IN    NS    ns1.c.is.
;; Received 189 bytes from 213.176.143.102#53(ns2.c.is) in 75 ms

Problem:

If the  DNS resolver configured in the operating system where "dig +trace" is uses is a unbound DNS Server, the "+trace" function might fail:
% dig menandmice.com +trace              

; <<>> DiG 9.7.1-P2 <<>> menandmice.com +trace
;; global options: +cmd
;; Received 12 bytes from 192.168.1.2#53(192.168.1.2) in 7 ms

The reason for this is that dig sends the very first query for the list of root-dns servers as an iterative query to the local resolving DNS Server. An iterative query is a query where the RD-Flag in the DNS query package is not set (RD=recursion desired). Iterative queries are usually used between a resolving DNS Server and an authoritative DNS Server. Client systems send recursive queries (RD flag set= recursion desired). Unbound is a recursive DNS Server, and it is build to answer recursive queries, not iterative queries (it is not an authoritative DNS Server). In the default configuration, unbound will refuse an iterative query:
% tcpdump port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:43:08.395457 IP 192.168.1.27.49292 > blackbox.home.strotmann.de.domain: 35413 NS? . (17)
18:43:08.396182 IP blackbox.home.strotmann.de.domain > 192.168.1.27.49292: 35413 Refused- [0q] 0/0/0 (12)
We see that also if we simulate the first query dig sends in the "+trace" function:
% dig ns . +norecur   

; <<>> DiG 9.7.1-P2 <<>> ns . +norecur
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 81
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 8 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Fri Aug 27 18:48:52 2010
;; MSG SIZE  rcvd: 12

The return code is "REFUSED", the query was administratively denied.

Other recursive DNS Servers on the market will not refuse iterative queries for zones they are not authoritative for, they will instead answer with a referral returning the "best" answer they have for the query. In the case of "+trace", this is the list of the root DNS servers as configured in the root hints or loaded during the root-NS priming phase.

Why is unbound refusing this kind of query? There are security aspects of sending referrals from the cache.
  1. it allows anyone from the outside to inspect the cache content. The cache content of a DNS Server can be used as a convert channel to transport data in a hidden channel (see Dan Kaminsky --> www.blackhat.com/presentations/bh-usa-04/bh-us-04-kaminsky/bh-us-04-kaminsky.ppt)
  2. the referral will have a much bigger size then the initial request. This creates the risk that this effect is misused to create a distributed denial of service attack (so called DNS amplification attacks: www.us-cert.gov/reading_room/DNS-recursion033006.pdf and www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-dnsamp.pdf )
  3. it can be used to see which domains are not in the cache, which is useful to know for cache poisoning.

Solution

It is possible to use "dig +trace" by specifying one of the root-DNS servers for the initial query:
dig menandmice.com +trace @a.root-servers.net

 

However for users of unbound that do not want to miss the "+trace" function of dig can configure unbound in a way that it allows iterative (no-recursive) queries. This is done by using the "allow_snoop" option in the access-control statement:
 

access-control: 192.0.2.0/24 allow_snoop
access-control: 127.0.0.0/8 allow_snoop
access-control: 10.0.0.0/8 allow
access-control: 2001:db8:2b6::0/64 allow
For security reasons (see above) it is recommended to enable "allow_snoop" only for administrative networks, not for the general client networks that use the unbound DNS Server.