<html><head><title>Re: BIND server; dig vs dig +trace on failing lookup.</title>
<meta charset="utf-8" http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 9pt;">Let me take a swing at it. If I'm wrong, someone correct me.<br>
<br>
1) dig the name servers for the 1st level domain. (In this case, it's a .com.)<br>
# dig +short com. NS<br>
c.gtld-servers.net.<br>
f.gtld-servers.net.<br>
j.gtld-servers.net.<br>
l.gtld-servers.net.<br>
k.gtld-servers.net.<br>
d.gtld-servers.net.<br>
g.gtld-servers.net.<br>
i.gtld-servers.net.<br>
a.gtld-servers.net.<br>
e.gtld-servers.net.<br>
m.gtld-servers.net.<br>
b.gtld-servers.net.<br>
h.gtld-servers.net.<br>
---<br>
<br>
2) How, ask one of those name servers for the NS for the target domain. (cistus.com. in this case.)<br>
<br>
# dig +norec @i.gtld-servers.net. cistus.com. NS<br>
<br>
; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> +norec @i.gtld-servers.net. cistus.com. NS<br>
; (2 servers found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49843<br>
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 4096<br>
;; QUESTION SECTION:<br>
;cistus.com.                    IN      NS<br>
<br>
;; AUTHORITY SECTION:<br>
cistus.com.             172800  IN      NS      srvns.pacifier.com.<br>
cistus.com.             172800  IN      NS      webns.pacifier.com.<br>
<br>
;; ADDITIONAL SECTION:<br>
srvns.pacifier.com.     172800  IN      A       216.65.128.5<br>
webns.pacifier.com.     172800  IN      A       216.65.128.1<br>
<br>
---<br>
<br>
3) Finally, query the records in the additional section to see if they match the glue records.<br>
<br>
# dig srvns.pacifier.com.<br>
<br>
; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> srvns.pacifier.com.<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17445<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 4096<br>
; COOKIE: d16ea0cbd520a81cea1154c1603ef7e13d586e8adc0e75f3 (good)<br>
;; QUESTION SECTION:<br>
;srvns.pacifier.com.            IN      A<br>
<br>
;; ANSWER SECTION:<br>
srvns.pacifier.com.     85728   IN      A       64.255.237.241<br>
<br>
;; AUTHORITY SECTION:<br>
pacifier.com.           172126  IN      NS      ns2.iinet.com.<br>
pacifier.com.           172126  IN      NS      ns4.iinet.com.<br>
pacifier.com.           172126  IN      NS      ns1.iinet.com.<br>
pacifier.com.           172126  IN      NS      ns3.iinet.com.<br>
----<br>
<br>
(glue) srvns.pacifier.com.     172800  IN      A       216.65.128.5<br>
vs<br>
(regular lookup) srvns.pacifier.com.     85728   IN      A       64.255.237.241<br>
<br>
And they don't - so we know the glue is stale.<br>
<br>
<br>
Is that right? :)<br>
<br>
-Greg<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td  width=3 bgcolor= #0000ff><br>
</td>
<td ><span style=" font-family:'courier new'; font-size: 9pt;">Would you mind showing me how you got there?<br>
[The answer is fab, obviously. But give a man a fish...and all that. :) ]<br>
<br>
-Greg<br>
<br>
<br>
<br>
<span style=" color: #800000;"><b>MA> The COM servers have stale glue<br>
<br>
MA> srvns.pacifier.com.     172800  IN      A       216.65.128.5<br>
MA> webns.pacifier.com.     172800  IN      A       216.65.128.1<br>
<br>
MA> vs<br>
<br>
MA> srvns.pacifier.com.     86400   IN      A       64.255.237.241<br>
MA> webns.pacifier.com.     86400   IN      A       64.255.237.240<br>
<br>
MA> The later set of servers are what you query when you run dig +trace.<br>
MA> If you prime the cache the plain lookup should work.  Report the out<br>
MA> of date glue to the zone administrator.<br>
<br>
MA> Mark<br>
<br>
>> On 3 Mar 2021, at 13:06, Gregory Sloop <</b></span></span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:gregs@sloop.net">gregs@sloop.net</a><span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b>> wrote:<br>
<br>
>> I've got a case, (and I see several other similar reports) where BIND is failing to find an A record for a domain.<br>
>> Yet a dig +trace does.<br>
<br>
>> (I'm doing the dig on the BIND server. It's set to be a root resolving server, not a forwarder.)<br>
<br>
>> 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.<br>
>> So, I can see how +trace would deliver different results than simply dig-ing - provided that +trace does involve resolve.conf.<br>
<br>
>> Here's a plain dig, using the BIND server itself - from the console.<br>
>> ---<br>
>> dig cistus.com @10.8.20.5<br>
<br>
>> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5<br>
>> ;; global options: +cmd<br>
>> ;; Got answer:<br>
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786<br>
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br>
<br>
>> ;; OPT PSEUDOSECTION:<br>
>> ; EDNS: version: 0, flags:; udp: 4096<br>
>> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good)<br>
>> ;; QUESTION SECTION:<br>
>> ;cistus.com.                    IN      A<br>
<br>
>> ;; Query time: 0 msec<br>
>> ;; SERVER: 10.8.20.5#53(10.8.20.5)<br>
>> ;; WHEN: Fri Feb 26 12:18:24 PST 2021<br>
>> ;; MSG SIZE  rcvd: 67<br>
<br>
>> ---<br>
<br>
>> I could post the dig +trace, if it adds any information, but I suspect it doesn't.<br>
<br>
>> So, what methods or steps might I take to figure out why the above lookup/dig fails?<br>
>> [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.]<br>
<br>
>> 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.<br>
>> So, can someone point me at a good source for a how-to/walk-through? A previous list posting?<br>
<br>
>> Again, the question is; what methods or steps (best practices) might I take to figure out why the above lookup/dig fails?<br>
<br>
>> TIA<br>
>> -Greg<br>
>> _______________________________________________<br>
>> Please visit </b></span><a style=" font-family:'courier new'; font-size: 9pt;" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a><span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b> to unsubscribe from this list<br>
<br>
>> ISC funds the development of this software with paid support subscriptions. Contact us at </b></span><a style=" font-family:'courier new'; font-size: 9pt;" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a><span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b> for more information.<br>
<br>
<br>
>> bind-users mailing list<br>
</b></span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:bind-users@lists.isc.org">>> bind-users@lists.isc.org</a><br>
<a style=" font-family:'courier new'; font-size: 9pt;" href="https://lists.isc.org/mailman/listinfo/bind-users">>> https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</td>
</tr>
</table>
</body></html>