Can't dig +trace?

Unbound
1

I have unbound running and clients using dig seem not to be able to trace?

dig +trace www.amiga.com

; <<>> DiG 9.6.2-P2 <<>> +trace www.amiga.com
;; global options: +cmd
;; Received 12 bytes from <MY-UNBOUND-IP>#53(MY-UNBOUND-IP) in 0 ms

However if I hit Google's lookup servers with the same command from the same client machine, I get the expected response...

dig +trace @8.8.8.8 www.amiga.com

; <<>> DiG 9.6.2-P2 <<>> +trace @8.8.8.8 www.amiga.com
; (1 server found)
;; global options: +cmd
. 8647 IN NS b.root-servers.net.
. 8647 IN NS g.root-servers.net.
. 8647 IN NS c.root-servers.net.
. 8647 IN NS i.root-servers.net.
. 8647 IN NS j.root-servers.net.
. 8647 IN NS h.root-servers.net.
. 8647 IN NS e.root-servers.net.
. 8647 IN NS m.root-servers.net.
. 8647 IN NS f.root-servers.net.
. 8647 IN NS a.root-servers.net.
. 8647 IN NS l.root-servers.net.
. 8647 IN NS k.root-servers.net.
. 8647 IN NS d.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms

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

amiga.com. 172800 IN NS ns15.domaincontrol.com.
amiga.com. 172800 IN NS ns16.domaincontrol.com.
;; Received 115 bytes from 192.12.94.30#53(e.gtld-servers.net) in 126 ms

www.amiga.com. 3600 IN CNAME amiga.com.
amiga.com. 600 IN A 68.115.249.34
amiga.com. 3600 IN NS ns16.domaincontrol.com.
amiga.com. 3600 IN NS ns15.domaincontrol.com.
;; Received 113 bytes from 208.109.255.8#53(ns16.domaincontrol.com) in 24 ms

drill -T www.amiga.com seems to do the job these days. I guess I am just mostly curious what about Unbound keeps good ol' dig +trace from working?

TIA

FONG

2

control which clients are allowed to make (recursive) queries

to this server. Specify classless netblocks with /size and action.

By default everything is refused, except for localhost.

Choose deny (drop message), refuse (polite error reply),

allow (recursive ok), allow_snoop (recursive and nonrecursive ok)

access-control: 0.0.0.0/0 refuse

access-control: 127.0.0.0/8 allow_snoop

3

Fongaboo via Unbound-users writes:

>
>
> I have unbound running and clients using dig seem not to be able to trace?
>
>
> dig +trace www.amiga.com
>
> ; <<>> DiG 9.6.2-P2 <<>> +trace www.amiga.com
> ;; global options: +cmd
> ;; Received 12 bytes from <MY-UNBOUND-IP>#53(MY-UNBOUND-IP) in 0 ms
>
>
> However if I hit Google's lookup servers with the same command from the
> same client machine, I get the expected response...

The +trace option causes dig not to use the local resolver. From the
dig manual:

      +[no]trace
           Toggle tracing of the delegation path from the root name servers
           for the name being looked up. Tracing is disabled by default. When
           tracing is enabled, dig makes iterative queries to resolve the name
           being looked up. It will follow referrals from the root servers,
           showing the answer from each server that was used to resolve the
           lookup.

So it is unlikely that this is related to unbound.

  jaap

4

Not quite. If you use the +trace option, dig makes *one* query to its
local resolver(s) to get a list of root name servers. Thereafter, it
makes its own iterative queries. However, that initial query has RD=0,
and unbound won't answer. Anonymous fongaboo will have to specifically
allow cache snooping in unbound for this.

This is a weird design choice in dig. It shouldn't rely on any resolvers
for the initial query. It should just use a built-in list of root name
servers, and prime itself, just like BIND does.

Regards,
Anand

5

Thanks for everyone's responses. An enlightening thread, and I fully understand now.

FONG