Solved DIG +trace not working

rtwingfield

rtwingfield

dig +trace google.com (eg. google.com et.al.) seems not to work as the following indicates it should:

. . .from dig(1)

+[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.
Click to expand...

FYI, running BIND 9.10.2.

. . .rather it returns with:

# dig +trace google.com
(Doesn't work with any FQDN or IP address.)

; <<>> DiG 9.10.2 <<>> +trace google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
Click to expand...

. . .so how would one trace resolution with dig?
 
Looks like a DNS problem to me. Does dig(1) work for you at all? Using dig +trace google.com does work for me here. I tried it from one of our company FreeBSD servers after login to it with ssh(1) and from my Netbook running Linux here at home.
 
Seems to be associated with the +trace option. Here is the result of

# dig +notrace google.com (+notrace s/b the default)

; <<>> DiG 9.10.2 <<>> +notrace google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64777
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 54 IN A 173.194.115.71
google.com. 54 IN A 173.194.115.78
google.com. 54 IN A 173.194.115.73
google.com. 54 IN A 173.194.115.67
google.com. 54 IN A 173.194.115.72
google.com. 54 IN A 173.194.115.68
google.com. 54 IN A 173.194.115.70
google.com. 54 IN A 173.194.115.69
google.com. 54 IN A 173.194.115.64
google.com. 54 IN A 173.194.115.65
google.com. 54 IN A 173.194.115.66

;; Query time: 31 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Sun Oct 18 17:43:37 CDT 2015
;; MSG SIZE rcvd: 215
Click to expand...
 
Results of
# dig @8.8.8.8 +trace google.com
(. . .not sure what all this means?) The command operation took a while to finish . . .must have generated a lot of traffic hammering on a lot of google servers. My understanding of the "server" parameter is to specify the name of the name server to query. The following results looks like it "dug" up every name-related server in "google world".

; <<>> DiG 9.10.2 <<>> @8.8.8.8 +trace google.com
; (1 server found)
;; global options: +cmd
. 7540 IN NS k.root-servers.net.
. 7540 IN NS a.root-servers.net.
. 7540 IN NS h.root-servers.net.
. 7540 IN NS g.root-servers.net.
. 7540 IN NS l.root-servers.net.
. 7540 IN NS i.root-servers.net.
. 7540 IN NS b.root-servers.net.
. 7540 IN NS j.root-servers.net.
. 7540 IN NS e.root-servers.net.
. 7540 IN NS c.root-servers.net.
. 7540 IN NS d.root-servers.net.
. 7540 IN NS m.root-servers.net.
. 7540 IN NS f.root-servers.net.
. 7540 IN RRSIG NS 8 0 518400 20151029050000 20151019040000 62530 . Z14ioZDiD0ZuyzxyNJyD4ECGUwhEBNCG9j2EWvMDpwyUUK8QTZNBzQMJ XURogZkIsBwPxwUB9RyzKRkQQTRA5Z2G9hKo0BSXN8402RE6fK+Dln34 3rbtBBrV2Ks6AkOmxMO8dfEyjJsbDmkqr4npsXQOMEYC0NFbq7amCVmj EAA=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 31 ms

com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20151029050000 20151019040000 62530 . k1MC1ODSeQG8xS80ptZ4dXQIdJLoHOircGxCIISjcj39SDiffUXNF4wm M+uEdf+Q1eLoh4NL5gn1VSANZg8k8aecUzvbcqJ4/SpPkCrRb+I4JO2X phBcupgVMeRPQILE4waIE3c8j2cBTEbGQ++/+jMv1g8ufZVfLmz/09hz s88=
;; Received 734 bytes from 192.112.36.4#53(g.root-servers.net) in 43 ms

google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20151023045516 20151016034516 51797 com. YO+ivqYqFW9DButM1ugCzrqCKej/ZvIHfpgGqPWEKiodLniOfwiA4q93 g7+YYPRasu3bVhgBLPjPNa7xysAh/wST9O8mEjahGG3dUIV/Jb5nu2Q6 lxujHXcjjFxRwDRi/g598cOEUv3s9dJ1wWHRsEqH6Poe5PVYfwVlWb+p PDE=
S84AE3BIT99DKIHQH27TRC0584HV5KOH.com. 86400 IN NSEC3 1 1 0 - S84J17P3PT4RKMEJOHNGD73C5Q5NV5S9 NS DS RRSIG
S84AE3BIT99DKIHQH27TRC0584HV5KOH.com. 86400 IN RRSIG NSEC3 8 2 86400 20151025043713 20151018032713 51797 com. tOly+JuxwEJrPbnd0KXCa8QstoD/HXAHzOTbKAltGGq2QvFLo1g201Fp GU0CjtEa/KD8cajs8gZ1ZvqjPrGVOF9lYg8/O6UfKn2wGg3r2njsEQ4b oWd15R2CXB9MwXPi1QmXmK9ThvXE6c2eD3lxGHCI6vs4qmsIf62syPqq /EY=
;; Received 660 bytes from 192.5.6.30#53(a.gtld-servers.net) in 62 ms

google.com. 300 IN A 74.125.227.224
google.com. 300 IN A 74.125.227.238
google.com. 300 IN A 74.125.227.226
google.com. 300 IN A 74.125.227.227
google.com. 300 IN A 74.125.227.229
google.com. 300 IN A 74.125.227.230
google.com. 300 IN A 74.125.227.228
google.com. 300 IN A 74.125.227.232
google.com. 300 IN A 74.125.227.231
google.com. 300 IN A 74.125.227.233
google.com. 300 IN A 74.125.227.225
;; Received 204 bytes from 216.239.32.10#53(ns1.google.com) in 39 ms
Click to expand...

BTW, all I'm really wanting to determine is why my rDNS lookup is not working . . .i.e., is it a fault of my configuration, or still AT&T's failure to properly delegate or otherwise allow the rDNS lookup (. . .since converting to AT&T's U-verse)? See https://forums.freebsd.org/threads/reverse-dns-not-resolving.53410/
 
You must log in or register to reply here.
Back
Top