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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Gregory Sloop
BIND server; dig vs dig +trace on failing lookup. 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Mark Andrews
The COM servers have stale glue

srvns.pacifier.com. 172800 IN A 216.65.128.5
webns.pacifier.com. 172800 IN A 216.65.128.1

vs

srvns.pacifier.com. 86400 IN A 64.255.237.241
webns.pacifier.com. 86400 IN A 64.255.237.240

The later set of servers are what you query when you run dig +trace.
If you prime the cache the plain lookup should work.  Report the out
of date glue to the zone administrator.

Mark

> On 3 Mar 2021, at 13:06, Gregory Sloop <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Gregory Sloop
Re: BIND server; dig vs dig +trace on failing lookup. 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 <
[hidden email]> 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
[hidden email]
>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Gregory Sloop
Re: BIND server; dig vs dig +trace on failing lookup. Let me take a swing at it. If I'm wrong, someone correct me.

1) dig the name servers for the 1st level domain. (In this case, it's a .com.)
# dig +short com. NS
c.gtld-servers.net.
f.gtld-servers.net.
j.gtld-servers.net.
l.gtld-servers.net.
k.gtld-servers.net.
d.gtld-servers.net.
g.gtld-servers.net.
i.gtld-servers.net.
a.gtld-servers.net.
e.gtld-servers.net.
m.gtld-servers.net.
b.gtld-servers.net.
h.gtld-servers.net.
---

2) How, ask one of those name servers for the NS for the target domain. (cistus.com. in this case.)

# dig +norec @i.gtld-servers.net. cistus.com. NS

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> +norec @i.gtld-servers.net. cistus.com. NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49843
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

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

;; AUTHORITY SECTION:
cistus.com.             172800  IN      NS      srvns.pacifier.com.
cistus.com.             172800  IN      NS      webns.pacifier.com.

;; ADDITIONAL SECTION:
srvns.pacifier.com.     172800  IN      A       216.65.128.5
webns.pacifier.com.     172800  IN      A       216.65.128.1

---

3) Finally, query the records in the additional section to see if they match the glue records.

# dig srvns.pacifier.com.

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> srvns.pacifier.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17445
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d16ea0cbd520a81cea1154c1603ef7e13d586e8adc0e75f3 (good)
;; QUESTION SECTION:
;srvns.pacifier.com.            IN      A

;; ANSWER SECTION:
srvns.pacifier.com.     85728   IN      A       64.255.237.241

;; AUTHORITY SECTION:
pacifier.com.           172126  IN      NS      ns2.iinet.com.
pacifier.com.           172126  IN      NS      ns4.iinet.com.
pacifier.com.           172126  IN      NS      ns1.iinet.com.
pacifier.com.           172126  IN      NS      ns3.iinet.com.
----

(glue) srvns.pacifier.com.     172800  IN      A       216.65.128.5
vs
(regular lookup) srvns.pacifier.com.     85728   IN      A       64.255.237.241

And they don't - so we know the glue is stale.


Is that right? :)

-Greg


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 <
[hidden email]> 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
[hidden email]
>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Mark Andrews
In reply to this post by Gregory Sloop
dig +trace +all and it stood out.

> On 3 Mar 2021, at 13:20, Gregory Sloop <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
In reply to this post by Gregory Sloop
Gregory Sloop <[hidden email]> wrote:

> Would you mind showing me how you got there?

I like https://dnsviz.net/ and https://zonemaster.net/ - dnsviz is better
at showing DNSSEC issues, and zonemaster has a bigger collection of
general DNS checks, so it's worth using them both.

Tony.
--
f.anthony.n.finch  <[hidden email]>  https://dotat.at/
Southwest Fitzroy: Cyclonic 4 to 6, occasionally 3 at first, becoming
easterly or northeasterly later. Moderate or rough. Showers, thundery at
first. Good, occasionally poor.

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users