Subject: [DNSOP] Unexpected behaviour of dig +trace

From: Florian Streibelt <[email-masked]>
Date: Wed, 26 Mar 2014 10:22:27 +0100

Hello DNS ops,

last week I discovered something that I personally would consider a bug in
binds dig utility, at least the behaviour was unexpected for me.

Summary: too many dns requests, using the system resolver although told
otherwise.

My question now is: bug or feature?

Currently I am implementing a little testbed that simulates the DNS
hiererchy, including root servers, TLD servers and so on.

I thought it would be nice to let the dig utility show me the delegations it 
follows when resolving www.example.org in my testbed, using the +trace option, 
and starting by one of the simulated rootservers. Like so:

$ dig +trace www.example.org @10.1.1.1

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace www.example.org @10.1.1.1
;; global options: +cmd
.           2   IN  NS  a.root-servers.net.
.           2   IN  NS  a.root-servers.net.
;; Received 77 bytes from 10.1.1.1#53(10.1.1.1) in 5 ms

org.            172800  IN  NS  d0.org.afilias-nst.org.
org.            172800  IN  NS  b2.org.afilias-nst.org.
org.            172800  IN  NS  b0.org.afilias-nst.org.
org.            172800  IN  NS  c0.org.afilias-nst.info.
org.            172800  IN  NS  a2.org.afilias-nst.info.
org.            172800  IN  NS  a0.org.afilias-nst.info.
;; Received 435 bytes from 198.41.0.4#53(198.41.0.4) in 188 ms

example.org.        86400   IN  NS  a.iana-servers.net.
example.org.        86400   IN  NS  b.iana-servers.net.
;; Received 81 bytes from 199.19.56.1#53(199.19.56.1) in 186 ms

www.example.org.    86400   IN  A   93.184.216.119
example.org.        172800  IN  NS  b.iana-servers.net.
example.org.        172800  IN  NS  a.iana-servers.net.
;; Received 185 bytes from 199.43.133.53#53(199.43.133.53) in 192 ms

As you can see, immedeately after the first lookup the dig utility leaves my
testbed, which consists of a simulated 10/8,  and runs right off the Internet.

The reason is that dig uses the system resolver from resolv.conf for all but
the initial query and the direct queries to the authoritative servers.

This can easily by validated when you look at a pcap trace from something like

$ dig +trace www.tu-berlin.de @198.41.0.4

or 

$ dig +trace -4 www.tu-berlin.de @198.41.0.4

For reference I attached a plot generated by wireshark for the second command,
limiting the packet count from 94 to 52 packets.

cheers,
  Florian

-- 
Florian Streibelt, Dipl.-Inf.        building MAR, 4th floor, room 4.004
Fachgebiet INET - Sekr. MAR 4-4          phone: +49 30 314 757 33
Technische Universität Berlin           gpg-fp: 5BE7 F008 8B83 9357 1108
Marchstrasse 23 - 10587 Berlin                  984A 3B8E A41F 82F6 1240

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Mar 2014 18:52:44 +0800

> My question now is: bug or feature?

"Feature", but does catch many folk by surprise.
I'd written a patch and given it to someone at ISC that makes dig
output a warning message if you hand it both the "+trace" and
"@server" options. Dunno what happened, but never got integrated...

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Evan Hunt <[email-masked]>
Date: Wed, 26 Mar 2014 16:41:32 +0000

> "@server" options. Dunno what happened, but never got integrated...

My apologies for not sending feedback directly. (That's something
we really need to work on.) IIRC, we opted to clarify the documentation
rather than add a warning to dig itself.  There's also a knowledge base
article on this topic at http://tinyurl.com/o37rpgm.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Doug Barton <[email-masked]>
Date: Fri, 28 Mar 2014 12:44:28 -0700

> article on this topic at http://tinyurl.com/o37rpgm.

Given that the number of people using the tool vastly exceeds the number 
who read the docs, multiplied by the number of times this comes up on 
bind-users (where this discussion should have happened in the first 
place), IMO also putting the warning in the tool makes more sense.

FWIW,

Doug

---

From: Cathy Almond <[email-masked]>
Date: Mon, 31 Mar 2014 11:52:32 +0100

> place), IMO also putting the warning in the tool makes more sense.

Feature request is #31814 (I merged Warren's original suggestion with a
later one asking for much the same).

Comments noted and I've 'prodded' this one for you (although the outcome
may depend on other factors, including future plans for the new delve
tool - see BIND 9.10.0b2).

Cathy