BIND server; dig vs dig +trace on failing lookup.

[Mark Andrews]

dig +trace +all and it stood out.

> On 3 Mar 2021, at 13:20, Gregory Sloop <gregs at sloop.net> wrote:
> 
> Would you mind showing me how you got there?
> [The answer is fab, obviously. But give a man a fish...and all that. :) ]
> 
> -Greg
> 
> 
> 
> MA> The COM servers have stale glue
> 
> MA> srvns.pacifier.com.     172800  IN      A       216.65.128.5
> MA> webns.pacifier.com.     172800  IN      A       216.65.128.1
> 
> MA> vs
> 
> MA> srvns.pacifier.com.     86400   IN      A       64.255.237.241
> MA> webns.pacifier.com.     86400   IN      A       64.255.237.240
> 
> MA> The later set of servers are what you query when you run dig +trace.
> MA> If you prime the cache the plain lookup should work.  Report the out
> MA> of date glue to the zone administrator.
> 
> MA> Mark
> 
> >> On 3 Mar 2021, at 13:06, Gregory Sloop <gregs at sloop.net> wrote:
> 
> >> I've got a case, (and I see several other similar reports) where BIND is failing to find an A record for a domain.
> >> Yet a dig +trace does.
> 
> >> (I'm doing the dig on the BIND server. It's set to be a root resolving server, not a forwarder.)
> 
> >> As I understand this, +trace will also involve resolve.conf options. And in this case, I've got Google DNS as one of the resolve.conf entries.
> >> So, I can see how +trace would deliver different results than simply dig-ing - provided that +trace does involve resolve.conf.
> 
> >> Here's a plain dig, using the BIND server itself - from the console.
> >> ---
> >> dig cistus.com @10.8.20.5
> 
> >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5
> >> ;; global options: +cmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786
> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> >> ;; OPT PSEUDOSECTION:
> >> ; EDNS: version: 0, flags:; udp: 4096
> >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good)
> >> ;; QUESTION SECTION:
> >> ;cistus.com.                    IN      A
> 
> >> ;; Query time: 0 msec
> >> ;; SERVER: 10.8.20.5#53(10.8.20.5)
> >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021
> >> ;; MSG SIZE  rcvd: 67
> 
> >> ---
> 
> >> I could post the dig +trace, if it adds any information, but I suspect it doesn't.
> 
> >> So, what methods or steps might I take to figure out why the above lookup/dig fails?
> >> [I intended +trace to do that, but since it's not doing the same thing a plain dig does, it's not very useful as a diagnostic tool.]
> 
> >> I've done some searching to see how to accomplish this, but it's a difficult question to frame without a ton of worthless hits.
> >> So, can someone point me at a good source for a how-to/walk-through? A previous list posting?
> 
> >> Again, the question is; what methods or steps (best practices) might I take to figure out why the above lookup/dig fails?
> 
> >> TIA
> >> -Greg
> >> _______________________________________________
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> >> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> >> bind-users mailing list
> >> bind-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org