[DNSOP] Unexpected behaviour of dig +trace
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 |Time | 130.149.x.y (local system)| 130.149.x.y (local resolver) | 194.246.96.1 | | | | 198.41.0.4| | 192.36.148.17 | | 130.149.7.7 | |0.0| Standard query 0x0f | | | | |DNS: Standard query 0x0fb6 NS Root | |(42361) -- (53) | | | | | |0.014763000| Standard query resp | | | | |DNS: Standard query response 0x0fb6 NS a.root-servers.net NS b.root-servers.net NS c.root-servers.net NS d.root-servers.net NS e.root-servers.net NS f.root-servers.net NS g.root-servers.net NS h.root-servers.net NS i.root-servers.net NS j.root-servers.net NS k.root-servers.net NS l.root-servers.net NS m.root-servers.net | |(42361) -- (53) | | | | | |0.016174000| Standard query 0x3c | | | | |DNS: Standard query 0x3c52 A a.root-servers.net | |(38944) -- (53) | | | | |0.017392000| Standard query resp | | | | |DNS: Standard query response 0x3c52 A 198.41.0.4 | |(38944) -- (53) | | | | |0.017787000| Standard query 0x08 | | | | |DNS: Standard query 0x087e A b.root-servers.net | |(44300) -- (53) | | | | |0.019293000| Standard query resp | | | | |DNS: Standard query response 0x087e A 192.228.79.201 | |(44300)
Re: [DNSOP] Unexpected behaviour of dig +trace
On Wed, Mar 26, 2014 at 5:22 PM, Florian Streibelt flor...@inet.tu-berlin.de wrote: 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? 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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unexpected behaviour of dig +trace
On Wed, Mar 26, 2014 at 06:52:44PM +0800, Warren Kumari wrote: 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... 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 -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
