Re: BIND server; dig vs dig +trace on failing lookup.
Gregory Sloop 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.finchhttps://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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND server; dig vs dig +trace on failing lookup.
dig +trace +all and it stood out. > On 3 Mar 2021, at 13:20, Gregory Sloop 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 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@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@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: ma...@isc.org ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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 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
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 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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND server; dig vs dig +trace on failing lookup.
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 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@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: ma...@isc.org ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
