Re: Bind 9.11 serving up false answers for a single domain.
I don't think tcpdump was installed by default with various versions of Debian that I set up in the last few years for networking. I didn't bother to install it, as it's output is different enough (old fashioned?) from the sharks to be annoying. It *was* installed with OpenSuSE 15.2 though. (OpenSuSE 15.2 -- the "stable" release that wants you to update something every day.) On Fri, 12 Feb 2021 00:35:53 + "John W. Blue via bind-users" wrote: > Most people like yourself that do not care about OS purity often are not > obligated (granted super broad generalization) to explain their changes to an > Enterprise Change Management Board (ECMB or similar) for deviations from a > "standard image". > > That is also 100% okay too. Those types of shops/sysadmins also typically > don't have a buckets of cash sitting around either so you work with makes > sense and use the resources available to get it done. > > The over-arching point is that the lowest common denominator for proper > troubleshooting is that tcpdump is useful and it does not need to be sourced > or installed. It is ready to go out of the box for nearly all situations > that could potentially be encountered. > > Usually. > > Murphy's law of unintended consequences should always be account for. > > John ___ 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 9.11 serving up false answers for a single domain.
Most people like yourself that do not care about OS purity often are not obligated (granted super broad generalization) to explain their changes to an Enterprise Change Management Board (ECMB or similar) for deviations from a "standard image". That is also 100% okay too. Those types of shops/sysadmins also typically don't have a buckets of cash sitting around either so you work with makes sense and use the resources available to get it done. The over-arching point is that the lowest common denominator for proper troubleshooting is that tcpdump is useful and it does not need to be sourced or installed. It is ready to go out of the box for nearly all situations that could potentially be encountered. Usually. Murphy's law of unintended consequences should always be account for. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of @lbutlr Sent: Thursday, February 11, 2021 6:18 PM To: bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. On 11 Feb 2021, at 16:38, John W. Blue via bind-users wrote: > I have found to tshark to be useful as well but the failing it has is that it > is generally not included in a unix OS distribution. Is bind? I mean, I have to install a bunch of stuff right off on a new bistro just to get a useable (for me) system. And if it's Linux I often have to UNinstall some things as well. I don't care about the purity of the distributions software set. -- Hey kids, shake it loose together the spotlight's hitting something That's been known to change the weather we'll kill the fatted calf tonight So stick around you're gonna hear electric music: Solid walls of sound ___ 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 9.11 serving up false answers for a single domain.
On 11 Feb 2021, at 16:38, John W. Blue via bind-users wrote: > I have found to tshark to be useful as well but the failing it has is that it > is generally not included in a unix OS distribution. Is bind? I mean, I have to install a bunch of stuff right off on a new bistro just to get a useable (for me) system. And if it's Linux I often have to UNinstall some things as well. I don't care about the purity of the distributions software set. -- Hey kids, shake it loose together the spotlight's hitting something That's been known to change the weather we'll kill the fatted calf tonight So stick around you're gonna hear electric music: Solid walls of sound ___ 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 9.11 serving up false answers for a single domain.
I have found to tshark to be useful as well but the failing it has is that it is generally not included in a unix OS distribution. Assuming anything referred to as "being in production" should also be following good change management protocols it makes sense to be fluent with tools that are readily accessible when a super fun session of all-of-sudden-troubleshooting breaks out. We recently had issues with a vendor that (I won't mention any names but it rhymes with proofpoint) where they insisted that the error we were having was on our side of the fence. They were basically unwilling to lift a finger to help. Color me shocked because I thought that how only Microsoft rolled. Packet captures proved that it was a load balancing code issue on their side and only then were they compelled to take action. Being able to correctly examine packets on the wire is a "must have" skillset to be an effective sysadmin. It can save the day or save your butt. @OP: very curious as to where you are at now in your troubleshooting. Status update? John -Original Message- From: Paul Kosinski [mailto:b...@iment.com] Sent: Wednesday, February 10, 2021 10:37 PM To: bind-users@lists.isc.org Cc: John W. Blue Subject: Re: Bind 9.11 serving up false answers for a single domain. I rather prefer tshark to tcpdump: it's essentially the command line version of wireshark, and thus has wireshark's protocol "dissecting" abilities. On Wed, 10 Feb 2021 22:20:08 + "John W. Blue via bind-users" wrote: > Three words: tcpdump and wireshark > > It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and > flow .. pen and paper .. I could go on but … > > Know them. Love them. They are your newest best friends. > > > > Using tcpdump IMHO should be the first tool anyone uses when troubleshooting > seemly unexplainable DNS weirdness. > > Knowing what is being put on the wire (or lack thereof) is critical since it > provides key factual data points that decisions can be made on. When running > tcpdump on the DNS server I personally prefer this command: > > tcpdump -n -i -s 65535 -w > > dash n is telling tcpdump that you do not want it to resolve hostnames. This > is an important option when doing DNS troubleshooting because you do not want > extra resolutions taking place. > dash s is saying gimme the full packet. > dash w is the name of the file you want the output saved in. > > After starting the command, run several queries from a host and ctrl+c to > exit. > > Once you get your file into wireshark now you can start slicing n dicing on > the data! > > Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us > > By using a filter of dns.flags.rcode == (number here) you can drive off into > the weeds and get super granular with sorting the data. For example > “dns.flags.rcode == 2” will show you all of the server failures for queries. > > It is hard to provide further guidance on what to do since what you find in > the pcap is only a starting point. > > Good hunting! > > As an aside I would like to mention that you do not need to travel home to > get situational awareness when the diggui.com website can be used instead. > > Also. For the people running .us tld .. SHA1 for DNSSEC .. really? > > https://dnsviz.net/d/state.ma.us/dnssec/ > > John ___ 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 9.11 serving up false answers for a single domain. (OT)
Thanks! That was the response I was looking for. Much appreciated! -- Ondřej Surý (He/Him) ond...@isc.org > On 11. 2. 2021, at 9:03, stuart@registry.godaddy wrote: > > Good to know. > > Will attach a task to the next our next KSK roll process. Should halve the > number of SHA1 DS's in the root. > > Will also tweak some of our other DNSSEC process documentation to stop > providing them. > > Stuart > > On 11/2/21, 6:49 pm, "bind-users on behalf of Ondřej Surý" > wrote: > >Notice: This email is from an external sender. > > > >> On 11. 2. 2021, at 7:01, Stuart@registry.godaddy wrote: >> >> It's one of those old compatibility things. > >Also called *downgrade attack vector*. > >Stuart, there’s absolutely no reason to keep any SHA1 in the DNS at the > time I am writing this message. > >Cheers, >Ondrej >-- >Ondřej Surý (He/Him) >ond...@isc.org > > > signature.asc Description: Message signed with OpenPGP ___ 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 9.11 serving up false answers for a single domain. (OT)
Good to know. Will attach a task to the next our next KSK roll process. Should halve the number of SHA1 DS's in the root. Will also tweak some of our other DNSSEC process documentation to stop providing them. Stuart On 11/2/21, 6:49 pm, "bind-users on behalf of Ondřej Surý" wrote: Notice: This email is from an external sender. > On 11. 2. 2021, at 7:01, Stuart@registry.godaddy wrote: > > It's one of those old compatibility things. Also called *downgrade attack vector*. Stuart, there’s absolutely no reason to keep any SHA1 in the DNS at the time I am writing this message. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@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 9.11 serving up false answers for a single domain. (OT)
I was going to throw out a “Of course not”, but after having a bit of a
stressful last few hours, I decided to walk the zone manually as something
“brainless” to relax..
And found there are some..
firmdale (RSASHS256 DNSKEY algorithm (8))
gdn (RSASHS256 DNSKEY algorithm (8))
na (RSASHA1 (NSEC) DNSKEY algorithm (5))
It seems there's some old hold outs..
But that's enough root zone walking for me for a while.
Stuart
From: Mark Elkins
Date: Thursday, 11 February 2021 at 6:42 pm
To: Stuart Browne , bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Notice: This email is from an external sender.
I think getting rid of SHA1 DS (DS type 1) records would be a reasonable thing
to do. They are weaker than SHA256 DS (DS type 2) records. Generally, in life,
making things simpler is a good idea and I believe that applies here too.
.COM only provides DS type 2 records in the root so if there were fundamental
problems - we would have heard by now.
@Stuart - So do any delegations in the root zone only have SHA1 DS records?
On 2/11/21 8:01 AM, mailto:Stuart@registry.godaddy wrote:
It's one of those old compatibility things.
A quick bit of analysis of the root zone:
1,370 delegations with DS records
697 SHA1 DS records
1,519 SHA2 DS records
Yes, these numbers don't add up; there are some double and triple DS record
sets in there.
So the US zone is by no means alone in keeping it around (at least 27 other
countries similarly have them).
I'm sure that in the not-too-distant future, they'll be phased out, but for now
we don't have that as an high priority piece of work.
Stuart
On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users"
mailto:bind-users-boun...@lists.isc.orgonbehalfofbind-us...@lists.isc.org wrote:
Notice: This email is from an external sender.
So out of curiosity why does the us tld have a SHA1 DS in root? Should be
an easy thing to tidy up, eh?
John
-Original Message-
From: mailto:Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
mailto:bind-users-boun...@lists.isc.orgonbehalfofbind-us...@lists.isc.org wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us.IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do .. some
don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: mailto:Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
(OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’
however, is delegated to the state officials of the Commonwealth of
Massachusetts and is indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users mailto:bind-users-boun...@lists.isc.org on behalf of
"John W. Blue via bind-users" mailto:bind-users@lists.isc.org Reply to: "John
W. Blue" mailto:john.b...@rrcic.com
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users mailto:bind-users@lists.isc.org
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb
and flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
Using tcpdump IMHO should be the first tool anyone uses when
troubleshooting seemly unexplainable DNS weirdness.
Knowing what is being put on the wire (or lack thereof) is critical
since it provides key factual data points that decisions can be made on. When
running tcpdump on the DNS server I personally prefer this comm
Re: Bind 9.11 serving up false answers for a single domain. (OT)
> On 11. 2. 2021, at 7:01, Stuart@registry.godaddy wrote: > > It's one of those old compatibility things. Also called *downgrade attack vector*. Stuart, there’s absolutely no reason to keep any SHA1 in the DNS at the time I am writing this message. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ 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 9.11 serving up false answers for a single domain. (OT)
I think getting rid of SHA1 DS (DS type 1) records would be a reasonable
thing to do. They are weaker than SHA256 DS (DS type 2) records.
Generally, in life, making things simpler is a good idea and I believe
that applies here too.
.COM only provides DS type 2 records in the root so if there were
fundamental problems - we would have heard by now.
@Stuart - So do any delegations in the root zone only have SHA1 DS records?
On 2/11/21 8:01 AM, Stuart@registry.godaddy wrote:
It's one of those old compatibility things.
A quick bit of analysis of the root zone:
1,370 delegations with DS records
697 SHA1 DS records
1,519 SHA2 DS records
Yes, these numbers don't add up; there are some double and triple DS record
sets in there.
So the US zone is by no means alone in keeping it around (at least 27 other
countries similarly have them).
I'm sure that in the not-too-distant future, they'll be phased out, but for now
we don't have that as an high priority piece of work.
Stuart
On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
So out of curiosity why does the us tld have a SHA1 DS in root? Should be
an easy thing to tidy up, eh?
John
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us.IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do ..
some don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
(OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’
however, is delegated to the state officials of the Commonwealth of
Massachusetts and is indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users on behalf of "John W. Blue via
bind-users" Reply to: "John W. Blue"
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper ..
ebb and flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
Using tcpdump IMHO should be the first tool anyone uses when
troubleshooting seemly unexplainable DNS weirdness.
Knowing what is being put on the wire (or lack thereof) is critical
since it provides key factual data points that decisions can be made on. When
running tcpdump on the DNS server I personally prefer this command:
tcpdump -n -i -s 65535 -w
dash n is telling tcpdump that you do not want it to resolve
hostnames. This is an important option when doing DNS troubleshooting because
you do not want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.
After starting the command, run several queries from a host and ctrl+c
to exit.
Once you get your file into wireshark now you can start slicing n
dicing on the data!
Here is handy wireshark filter: dns.qry.name ==
internet-dns1.state.ma.us
By using a filter of dns.flags.rcode == (number here) you can drive
off into the weeds and get super granular with sorting the data. For example
“dns.flags.rcode == 2” will show you all of the server failures for queries.
It is hard to provide further gui
Re: Bind 9.11 serving up false answers for a single domain. (OT)
It's one of those old compatibility things.
A quick bit of analysis of the root zone:
1,370 delegations with DS records
697 SHA1 DS records
1,519 SHA2 DS records
Yes, these numbers don't add up; there are some double and triple DS record
sets in there.
So the US zone is by no means alone in keeping it around (at least 27 other
countries similarly have them).
I'm sure that in the not-too-distant future, they'll be phased out, but for now
we don't have that as an high priority piece of work.
Stuart
On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
So out of curiosity why does the us tld have a SHA1 DS in root? Should be
an easy thing to tidy up, eh?
John
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us.IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do .. some
don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
(OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’
however, is delegated to the state officials of the Commonwealth of
Massachusetts and is indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users on behalf of "John
W. Blue via bind-users" Reply to: "John W. Blue"
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb
and flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
Using tcpdump IMHO should be the first tool anyone uses when
troubleshooting seemly unexplainable DNS weirdness.
Knowing what is being put on the wire (or lack thereof) is critical
since it provides key factual data points that decisions can be made on. When
running tcpdump on the DNS server I personally prefer this command:
tcpdump -n -i -s 65535 -w
dash n is telling tcpdump that you do not want it to resolve hostnames.
This is an important option when doing DNS troubleshooting because you do not
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.
After starting the command, run several queries from a host and ctrl+c
to exit.
Once you get your file into wireshark now you can start slicing n
dicing on the data!
Here is handy wireshark filter: dns.qry.name ==
internet-dns1.state.ma.us
By using a filter of dns.flags.rcode == (number here) you can drive off
into the weeds and get super granular with sorting the data. For example
“dns.flags.rcode == 2” will show you all of the server failures for queries.
It is hard to provide further guidance on what to do since what you
find in the pcap is only a starting point.
Good hunting!
As an aside I would like to mention that you do not need to travel home
to get situational awareness when the diggui.com website can be used instead.
Also. For the people running .us tld .. SHA1 for DNSSEC .. really?
https://dnsviz.net/d/state.ma.us/dnssec/
John
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
sami's strat
Sent: Wednesday, February 10
Re: Bind 9.11 serving up false answers for a single domain.
I rather prefer tshark to tcpdump: it's essentially the command line version of wireshark, and thus has wireshark's protocol "dissecting" abilities. On Wed, 10 Feb 2021 22:20:08 + "John W. Blue via bind-users" wrote: > Three words: tcpdump and wireshark > > It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and > flow .. pen and paper .. I could go on but … > > Know them. Love them. They are your newest best friends. > > > > Using tcpdump IMHO should be the first tool anyone uses when troubleshooting > seemly unexplainable DNS weirdness. > > Knowing what is being put on the wire (or lack thereof) is critical since it > provides key factual data points that decisions can be made on. When running > tcpdump on the DNS server I personally prefer this command: > > tcpdump -n -i -s 65535 -w > > dash n is telling tcpdump that you do not want it to resolve hostnames. This > is an important option when doing DNS troubleshooting because you do not want > extra resolutions taking place. > dash s is saying gimme the full packet. > dash w is the name of the file you want the output saved in. > > After starting the command, run several queries from a host and ctrl+c to > exit. > > Once you get your file into wireshark now you can start slicing n dicing on > the data! > > Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us > > By using a filter of dns.flags.rcode == (number here) you can drive off into > the weeds and get super granular with sorting the data. For example > “dns.flags.rcode == 2” will show you all of the server failures for queries. > > It is hard to provide further guidance on what to do since what you find in > the pcap is only a starting point. > > Good hunting! > > As an aside I would like to mention that you do not need to travel home to > get situational awareness when the diggui.com website can be used instead. > > Also. For the people running .us tld .. SHA1 for DNSSEC .. really? > > https://dnsviz.net/d/state.ma.us/dnssec/ > > John ___ 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 9.11 serving up false answers for a single domain. (OT)
So out of curiosity why does the us tld have a SHA1 DS in root? Should be an
easy thing to tidy up, eh?
John
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us.IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do .. some
don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’
however, is delegated to the state officials of the Commonwealth of
Massachusetts and is indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users on behalf of "John W.
Blue via bind-users" Reply to: "John W. Blue"
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and
flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
Using tcpdump IMHO should be the first tool anyone uses when
troubleshooting seemly unexplainable DNS weirdness.
Knowing what is being put on the wire (or lack thereof) is critical since
it provides key factual data points that decisions can be made on. When
running tcpdump on the DNS server I personally prefer this command:
tcpdump -n -i -s 65535 -w
dash n is telling tcpdump that you do not want it to resolve hostnames.
This is an important option when doing DNS troubleshooting because you do not
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.
After starting the command, run several queries from a host and ctrl+c to
exit.
Once you get your file into wireshark now you can start slicing n dicing on
the data!
Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us
By using a filter of dns.flags.rcode == (number here) you can drive off
into the weeds and get super granular with sorting the data. For example
“dns.flags.rcode == 2” will show you all of the server failures for queries.
It is hard to provide further guidance on what to do since what you find in
the pcap is only a starting point.
Good hunting!
As an aside I would like to mention that you do not need to travel home to
get situational awareness when the diggui.com website can be used instead.
Also. For the people running .us tld .. SHA1 for DNSSEC .. really?
https://dnsviz.net/d/state.ma.us/dnssec/
John
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
sami's strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
Thank you all for responding. One final query about this. I'm seeing this
issue on my production servers at work. Yet, when I run the same queries at
home, I don't see those failed queries. I actually flushed DNS cache, cleared
Linux O/S cache, and even bounced my personal DNS server trying to reproduce
the issue. But I could not.
TIA
On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you
the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us
@’ for all the addresses in the glue records.
e.g.
dig +dnssec +norec http://internet-dns1.state.ma.us
@http://146.243.122.17
Mark
> On 10 Feb 2021, at 14:50, sami's str
Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us.IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do .. some
don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’
however, is delegated to the state officials of the Commonwealth of
Massachusetts and is indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users on behalf of "John W.
Blue via bind-users" Reply to: "John W. Blue"
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and
flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
Using tcpdump IMHO should be the first tool anyone uses when
troubleshooting seemly unexplainable DNS weirdness.
Knowing what is being put on the wire (or lack thereof) is critical since
it provides key factual data points that decisions can be made on. When
running tcpdump on the DNS server I personally prefer this command:
tcpdump -n -i -s 65535 -w
dash n is telling tcpdump that you do not want it to resolve hostnames.
This is an important option when doing DNS troubleshooting because you do not
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.
After starting the command, run several queries from a host and ctrl+c to
exit.
Once you get your file into wireshark now you can start slicing n dicing on
the data!
Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us
By using a filter of dns.flags.rcode == (number here) you can drive off
into the weeds and get super granular with sorting the data. For example
“dns.flags.rcode == 2” will show you all of the server failures for queries.
It is hard to provide further guidance on what to do since what you find in
the pcap is only a starting point.
Good hunting!
As an aside I would like to mention that you do not need to travel home to
get situational awareness when the diggui.com website can be used instead.
Also. For the people running .us tld .. SHA1 for DNSSEC .. really?
https://dnsviz.net/d/state.ma.us/dnssec/
John
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
sami's strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
Thank you all for responding. One final query about this. I'm seeing this
issue on my production servers at work. Yet, when I run the same queries at
home, I don't see those failed queries. I actually flushed DNS cache, cleared
Linux O/S cache, and even bounced my personal DNS server trying to reproduce
the issue. But I could not.
TIA
On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you
the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us
@’ for all the addresses in the glue records.
e.g.
dig +dnssec +norec http://internet-dns1.state.ma.us
@http://146.243.122.17
Mark
> On 10 Feb 2021, at 14:50, sami's strat <mailto:sami.st...@gmail.com>
wrote:
>
> Thanks Mark.
>
> However, the traceroute to the hostnamed failed for the same reason.
Please note:
>
> [root@myhost data]# dig http://internet-dns1.state.ma.us
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <&l
RE: Bind 9.11 serving up false answers for a single domain. (OT)
Well .. as best as I can tell .. the us tld does has a SHA1 DS record: ;; QUESTION SECTION: ;us.IN DS ;; ANSWER SECTION: us. 50882 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 50882 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 Right? In checking other tld's looks like it is a mixed bag .. some do .. some don’t. ;; QUESTION SECTION: ;com. IN DS ;; ANSWER SECTION: com.78577 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 -Original Message- From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy] Sent: Wednesday, February 10, 2021 5:24 PM To: John W. Blue; bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT) If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ however, is delegated to the state officials of the Commonwealth of Massachusetts and is indeed RSASHA1NSEC3. Stuart ... one of the guy’s that does the DNSSEC for US TLD. From: bind-users on behalf of "John W. Blue via bind-users" Reply to: "John W. Blue" Date: Thursday, 11 February 2021 at 9:21 am To: bind-users Subject: RE: Bind 9.11 serving up false answers for a single domain. Notice: This email is from an external sender. Three words: tcpdump and wireshark It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and flow .. pen and paper .. I could go on but … Know them. Love them. They are your newest best friends. Using tcpdump IMHO should be the first tool anyone uses when troubleshooting seemly unexplainable DNS weirdness. Knowing what is being put on the wire (or lack thereof) is critical since it provides key factual data points that decisions can be made on. When running tcpdump on the DNS server I personally prefer this command: tcpdump -n -i -s 65535 -w dash n is telling tcpdump that you do not want it to resolve hostnames. This is an important option when doing DNS troubleshooting because you do not want extra resolutions taking place. dash s is saying gimme the full packet. dash w is the name of the file you want the output saved in. After starting the command, run several queries from a host and ctrl+c to exit. Once you get your file into wireshark now you can start slicing n dicing on the data! Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us By using a filter of dns.flags.rcode == (number here) you can drive off into the weeds and get super granular with sorting the data. For example “dns.flags.rcode == 2” will show you all of the server failures for queries. It is hard to provide further guidance on what to do since what you find in the pcap is only a starting point. Good hunting! As an aside I would like to mention that you do not need to travel home to get situational awareness when the diggui.com website can be used instead. Also. For the people running .us tld .. SHA1 for DNSSEC .. really? https://dnsviz.net/d/state.ma.us/dnssec/ John From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's strat Sent: Wednesday, February 10, 2021 11:54 AM To: Mark Andrews Cc: bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. Thank you all for responding. One final query about this. I'm seeing this issue on my production servers at work. Yet, when I run the same queries at home, I don't see those failed queries. I actually flushed DNS cache, cleared Linux O/S cache, and even bounced my personal DNS server trying to reproduce the issue. But I could not. TIA On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote: Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us @’ for all the addresses in the glue records. e.g. dig +dnssec +norec http://internet-dns1.state.ma.us @http://146.243.122.17 Mark > On 10 Feb 2021, at 14:50, sami's strat <mailto:sami.st...@gmail.com> wrote: > > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. Please > note: > > [root@myhost data]# dig http://internet-dns1.state.ma.us > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > http://internet-dns1.state.ma.us ;; global options: +cmd ;; Got > answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 ;; flags: > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;http://internet-dns1.state.ma.us. IN A > > ;; Query time: 1263 msec > ;; SER
Re: Bind 9.11 serving up false answers for a single domain. (OT)
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ however, is delegated to the state officials of the Commonwealth of Massachusetts and is indeed RSASHA1NSEC3. Stuart ... one of the guy’s that does the DNSSEC for US TLD. From: bind-users on behalf of "John W. Blue via bind-users" Reply to: "John W. Blue" Date: Thursday, 11 February 2021 at 9:21 am To: bind-users Subject: RE: Bind 9.11 serving up false answers for a single domain. Notice: This email is from an external sender. Three words: tcpdump and wireshark It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and flow .. pen and paper .. I could go on but … Know them. Love them. They are your newest best friends. Using tcpdump IMHO should be the first tool anyone uses when troubleshooting seemly unexplainable DNS weirdness. Knowing what is being put on the wire (or lack thereof) is critical since it provides key factual data points that decisions can be made on. When running tcpdump on the DNS server I personally prefer this command: tcpdump -n -i -s 65535 -w dash n is telling tcpdump that you do not want it to resolve hostnames. This is an important option when doing DNS troubleshooting because you do not want extra resolutions taking place. dash s is saying gimme the full packet. dash w is the name of the file you want the output saved in. After starting the command, run several queries from a host and ctrl+c to exit. Once you get your file into wireshark now you can start slicing n dicing on the data! Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us By using a filter of dns.flags.rcode == (number here) you can drive off into the weeds and get super granular with sorting the data. For example “dns.flags.rcode == 2” will show you all of the server failures for queries. It is hard to provide further guidance on what to do since what you find in the pcap is only a starting point. Good hunting! As an aside I would like to mention that you do not need to travel home to get situational awareness when the diggui.com website can be used instead. Also. For the people running .us tld .. SHA1 for DNSSEC .. really? https://dnsviz.net/d/state.ma.us/dnssec/ John From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's strat Sent: Wednesday, February 10, 2021 11:54 AM To: Mark Andrews Cc: bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. Thank you all for responding. One final query about this. I'm seeing this issue on my production servers at work. Yet, when I run the same queries at home, I don't see those failed queries. I actually flushed DNS cache, cleared Linux O/S cache, and even bounced my personal DNS server trying to reproduce the issue. But I could not. TIA On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote: Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us @’ for all the addresses in the glue records. e.g. dig +dnssec +norec http://internet-dns1.state.ma.us @http://146.243.122.17 Mark > On 10 Feb 2021, at 14:50, sami's strat <mailto:sami.st...@gmail.com> wrote: > > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. Please > note: > > [root@myhost data]# dig http://internet-dns1.state.ma.us > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > http://internet-dns1.state.ma.us > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;http://internet-dns1.state.ma.us. IN A > > ;; Query time: 1263 msec > ;; SERVER: 192.168.33.12#53(192.168.33.12) > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > ;; MSG SIZE rcvd: 54 > > [root@myhost data]# dig http://internet-dns1.state.ma.us +trace > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > http://internet-dns1.state.ma.us +trace > ;; global options: +cmd > . 516485 IN NS http://c.root-servers.net. > . 516485 IN NS http://e.root-servers.net. > . 516485 IN NS http://f.root-servers.net. > . 516485 IN NS http://l.root-servers.net. > . 516485 IN NS http://m.root-servers.net. > . 516485 IN NS http://d.root-servers.net. > . 516485 IN NS http://g.root-servers.net. > .
RE: Bind 9.11 serving up false answers for a single domain.
Three words: tcpdump and wireshark It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and flow .. pen and paper .. I could go on but … Know them. Love them. They are your newest best friends. Using tcpdump IMHO should be the first tool anyone uses when troubleshooting seemly unexplainable DNS weirdness. Knowing what is being put on the wire (or lack thereof) is critical since it provides key factual data points that decisions can be made on. When running tcpdump on the DNS server I personally prefer this command: tcpdump -n -i -s 65535 -w dash n is telling tcpdump that you do not want it to resolve hostnames. This is an important option when doing DNS troubleshooting because you do not want extra resolutions taking place. dash s is saying gimme the full packet. dash w is the name of the file you want the output saved in. After starting the command, run several queries from a host and ctrl+c to exit. Once you get your file into wireshark now you can start slicing n dicing on the data! Here is handy wireshark filter: dns.qry.name == internet-dns1.state.ma.us By using a filter of dns.flags.rcode == (number here) you can drive off into the weeds and get super granular with sorting the data. For example “dns.flags.rcode == 2” will show you all of the server failures for queries. It is hard to provide further guidance on what to do since what you find in the pcap is only a starting point. Good hunting! As an aside I would like to mention that you do not need to travel home to get situational awareness when the diggui.com website can be used instead. Also. For the people running .us tld .. SHA1 for DNSSEC .. really? https://dnsviz.net/d/state.ma.us/dnssec/ John From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's strat Sent: Wednesday, February 10, 2021 11:54 AM To: Mark Andrews Cc: bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. Thank you all for responding. One final query about this. I'm seeing this issue on my production servers at work. Yet, when I run the same queries at home, I don't see those failed queries. I actually flushed DNS cache, cleared Linux O/S cache, and even bounced my personal DNS server trying to reproduce the issue. But I could not. TIA On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews mailto:ma...@isc.org>> wrote: Run ‘dig +trace +all internet-dns1.state.ma.us<http://internet-dns1.state.ma.us>’ which will show you the glue records then try ‘dig +dnssec +norec internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> @’ for all the addresses in the glue records. e.g. dig +dnssec +norec internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> @146.243.122.17<http://146.243.122.17> Mark > On 10 Feb 2021, at 14:50, sami's strat > mailto:sami.st...@gmail.com>> wrote: > > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. Please > note: > > [root@myhost data]# dig > internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;internet-dns1.state.ma.us<http://internet-dns1.state.ma.us>. IN A > > ;; Query time: 1263 msec > ;; SERVER: 192.168.33.12#53(192.168.33.12) > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > ;; MSG SIZE rcvd: 54 > > [root@myhost data]# dig > internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> +trace > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > internet-dns1.state.ma.us<http://internet-dns1.state.ma.us> +trace > ;; global options: +cmd > . 516485 IN NS > c.root-servers.net<http://c.root-servers.net>. > . 516485 IN NS > e.root-servers.net<http://e.root-servers.net>. > . 516485 IN NS > f.root-servers.net<http://f.root-servers.net>. > . 516485 IN NS > l.root-servers.net<http://l.root-servers.net>. > . 516485 IN NS > m.root-servers.net<http://m.root-servers.net>. > . 516485 IN NS > d.root-servers.net<http://d.root-servers.net>. > . 516485 IN NS > g.root-servers.net<http://g.root-servers.net>. > . 516485 IN NS > k.roo
Re: Bind 9.11 serving up false answers for a single domain.
Because they are connected at different points in the network and as such see different network faults. The servers can all be working fine, it the connections between them that are not working. -- Mark Andrews > On 11 Feb 2021, at 04:54, sami's strat wrote: > > > Thank you all for responding. One final query about this. I'm seeing this > issue on my production servers at work. Yet, when I run the same queries at > home, I don't see those failed queries. I actually flushed DNS cache, > cleared Linux O/S cache, and even bounced my personal DNS server trying to > reproduce the issue. But I could not. > > TIA > >> On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews wrote: >> Run ‘dig +trace +all internet-dns1.state.ma.us’ which will show you the glue >> records then try ‘dig +dnssec +norec internet-dns1.state.ma.us @’ >> for >> all the addresses in the glue records. >> >> e.g. >> dig +dnssec +norec internet-dns1.state.ma.us @146.243.122.17 >> >> Mark >> >> > On 10 Feb 2021, at 14:50, sami's strat wrote: >> > >> > Thanks Mark. >> > >> > However, the traceroute to the hostnamed failed for the same reason. >> > Please note: >> > >> > [root@myhost data]# dig internet-dns1.state.ma.us >> > >> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us >> > ;; global options: +cmd >> > ;; Got answer: >> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 >> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> > >> > ;; OPT PSEUDOSECTION: >> > ; EDNS: version: 0, flags:; udp: 4096 >> > ;; QUESTION SECTION: >> > ;internet-dns1.state.ma.us. IN A >> > >> > ;; Query time: 1263 msec >> > ;; SERVER: 192.168.33.12#53(192.168.33.12) >> > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 >> > ;; MSG SIZE rcvd: 54 >> > >> > [root@myhost data]# dig internet-dns1.state.ma.us +trace >> > >> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us >> > +trace >> > ;; global options: +cmd >> > . 516485 IN NS c.root-servers.net. >> > . 516485 IN NS e.root-servers.net. >> > . 516485 IN NS f.root-servers.net. >> > . 516485 IN NS l.root-servers.net. >> > . 516485 IN NS m.root-servers.net. >> > . 516485 IN NS d.root-servers.net. >> > . 516485 IN NS g.root-servers.net. >> > . 516485 IN NS k.root-servers.net. >> > . 516485 IN NS b.root-servers.net. >> > . 516485 IN NS h.root-servers.net. >> > . 516485 IN NS a.root-servers.net. >> > . 516485 IN NS i.root-servers.net. >> > . 516485 IN NS j.root-servers.net. >> > . 516485 IN RRSIG NS 8 0 518400 >> > 202103 2021020922 42351 . >> > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f >> > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w >> > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG >> > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb >> > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK >> > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== >> > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms >> > >> > us. 172800 IN NS a.cctld.us. >> > us. 172800 IN NS b.cctld.us. >> > us. 172800 IN NS c.cctld.us. >> > us. 172800 IN NS e.cctld.us. >> > us. 172800 IN NS f.cctld.us. >> > us. 172800 IN NS k.cctld.us. >> > us. 86400 IN DS 21364 8 1 >> > 260D0461242BCF8F05473A08B05ED01E6FA59B9C >> > us. 86400 IN DS 21364 8 2 >> > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 >> > us. 86400 IN RRSIG DS 8 1 86400 >> > 202103 2021020922 42351 . >> > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ >> > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd >> > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ >> > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj >> > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR >> > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== >> > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms >> > >> > state.ma.us.7200IN NS internet-dns3.state.ma.us. >> > state.ma.us.7200IN NS internet-dns1.state.ma.us. >> > state.ma.us.7200IN NS internet-dns2.state.ma.us. >> >
Re: Bind 9.11 serving up false answers for a single domain.
Thank you all for responding. One final query about this. I'm seeing this issue on my production servers at work. Yet, when I run the same queries at home, I don't see those failed queries. I actually flushed DNS cache, cleared Linux O/S cache, and even bounced my personal DNS server trying to reproduce the issue. But I could not. TIA On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews wrote: > Run ‘dig +trace +all internet-dns1.state.ma.us’ which will show you the > glue > records then try ‘dig +dnssec +norec internet-dns1.state.ma.us > @’ for > all the addresses in the glue records. > > e.g. > dig +dnssec +norec internet-dns1.state.ma.us @146.243.122.17 > > Mark > > > On 10 Feb 2021, at 14:50, sami's strat wrote: > > > > Thanks Mark. > > > > However, the traceroute to the hostnamed failed for the same reason. > Please note: > > > > [root@myhost data]# dig internet-dns1.state.ma.us > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > internet-dns1.state.ma.us > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;internet-dns1.state.ma.us. IN A > > > > ;; Query time: 1263 msec > > ;; SERVER: 192.168.33.12#53(192.168.33.12) > > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > > ;; MSG SIZE rcvd: 54 > > > > [root@myhost data]# dig internet-dns1.state.ma.us +trace > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> > internet-dns1.state.ma.us +trace > > ;; global options: +cmd > > . 516485 IN NS c.root-servers.net. > > . 516485 IN NS e.root-servers.net. > > . 516485 IN NS f.root-servers.net. > > . 516485 IN NS l.root-servers.net. > > . 516485 IN NS m.root-servers.net. > > . 516485 IN NS d.root-servers.net. > > . 516485 IN NS g.root-servers.net. > > . 516485 IN NS k.root-servers.net. > > . 516485 IN NS b.root-servers.net. > > . 516485 IN NS h.root-servers.net. > > . 516485 IN NS a.root-servers.net. > > . 516485 IN NS i.root-servers.net. > > . 516485 IN NS j.root-servers.net. > > . 516485 IN RRSIG NS 8 0 518400 > 202103 2021020922 42351 . > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== > > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms > > > > us. 172800 IN NS a.cctld.us. > > us. 172800 IN NS b.cctld.us. > > us. 172800 IN NS c.cctld.us. > > us. 172800 IN NS e.cctld.us. > > us. 172800 IN NS f.cctld.us. > > us. 172800 IN NS k.cctld.us. > > us. 86400 IN DS 21364 8 1 > 260D0461242BCF8F05473A08B05ED01E6FA59B9C > > us. 86400 IN DS 21364 8 2 > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 > > us. 86400 IN RRSIG DS 8 1 86400 > 202103 2021020922 42351 . > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== > > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms > > > > state.ma.us.7200IN NS > internet-dns3.state.ma.us. > > state.ma.us.7200IN NS > internet-dns1.state.ma.us. > > state.ma.us.7200IN NS > internet-dns2.state.ma.us. > > state.ma.us.3600IN DS 47628 7 2 > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 > > state.ma.us.3600IN DS 41388 7 1 > 36D899932AF794EADD671161515E48FE829BB7FE > > state.ma.us.3600IN DS 41388 7 2 > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 > > state.ma.us.3600IN DS 47628 7 1 > 485E0EE2F7C08FCE51D1E284321242930274833A > >
Re: Bind 9.11 serving up false answers for a single domain.
Run ‘dig +trace +all internet-dns1.state.ma.us’ which will show you the glue records then try ‘dig +dnssec +norec internet-dns1.state.ma.us @’ for all the addresses in the glue records. e.g. dig +dnssec +norec internet-dns1.state.ma.us @146.243.122.17 Mark > On 10 Feb 2021, at 14:50, sami's strat wrote: > > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. Please > note: > > [root@myhost data]# dig internet-dns1.state.ma.us > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;internet-dns1.state.ma.us. IN A > > ;; Query time: 1263 msec > ;; SERVER: 192.168.33.12#53(192.168.33.12) > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > ;; MSG SIZE rcvd: 54 > > [root@myhost data]# dig internet-dns1.state.ma.us +trace > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > +trace > ;; global options: +cmd > . 516485 IN NS c.root-servers.net. > . 516485 IN NS e.root-servers.net. > . 516485 IN NS f.root-servers.net. > . 516485 IN NS l.root-servers.net. > . 516485 IN NS m.root-servers.net. > . 516485 IN NS d.root-servers.net. > . 516485 IN NS g.root-servers.net. > . 516485 IN NS k.root-servers.net. > . 516485 IN NS b.root-servers.net. > . 516485 IN NS h.root-servers.net. > . 516485 IN NS a.root-servers.net. > . 516485 IN NS i.root-servers.net. > . 516485 IN NS j.root-servers.net. > . 516485 IN RRSIG NS 8 0 518400 202103 > 2021020922 42351 . > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms > > us. 172800 IN NS a.cctld.us. > us. 172800 IN NS b.cctld.us. > us. 172800 IN NS c.cctld.us. > us. 172800 IN NS e.cctld.us. > us. 172800 IN NS f.cctld.us. > us. 172800 IN NS k.cctld.us. > us. 86400 IN DS 21364 8 1 > 260D0461242BCF8F05473A08B05ED01E6FA59B9C > us. 86400 IN DS 21364 8 2 > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 > us. 86400 IN RRSIG DS 8 1 86400 202103 > 2021020922 42351 . > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms > > state.ma.us.7200IN NS internet-dns3.state.ma.us. > state.ma.us.7200IN NS internet-dns1.state.ma.us. > state.ma.us.7200IN NS internet-dns2.state.ma.us. > state.ma.us.3600IN DS 47628 7 2 > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 > state.ma.us.3600IN DS 41388 7 1 > 36D899932AF794EADD671161515E48FE829BB7FE > state.ma.us.3600IN DS 41388 7 2 > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 > state.ma.us.3600IN DS 47628 7 1 > 485E0EE2F7C08FCE51D1E284321242930274833A > state.ma.us.3600IN RRSIG DS 8 3 3600 20210307200856 > 20210205191212 53985 us. > O8KqBHzlZsDqrZi0NQO4JEiN0b8j04/Lb8W2uVz5PyrAat1VgZKQ3Ws6 > 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf > nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN > +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA== > couldn't get address for 'internet-dns3.state.ma.us': not found > couldn't get address for 'internet-dns1.state.ma.us': not found > couldn't get address for
Re: Bind 9.11 serving up false answers for a single domain.
Do you know about mxtoolbox.com? It (and other similar sites) does a good job of diagnosing DNS-related problems. I use it now and then to check out my own sites, as it gives a "second opinion". In particular its "DNS Lookup' function reported the following for "internet-dns1.state.ma.us" Type Domain Name IP Address TTL A internet-dns1.state.ma.us 170.63.70.3615 min ... Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:44:08 PM (UTC -6), just for you. But its "DNS Check" function them reported dns:internet-dns1.state.ma.us No Results Found ... Reported by internet-dns2.state.ma.us on 2/9/2021 at 10:51:04 PM (UTC -6) and later ... Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:54:13 PM (UTC -6) Strange indeed: sounds like they have problems. On Tue, 9 Feb 2021 22:50:19 -0500 "sami's strat" wrote: > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. > Please note: > > [root@myhost data]# dig internet-dns1.state.ma.us > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;internet-dns1.state.ma.us. IN A > > > > ;; Query time: 1263 msec > > ;; SERVER: 192.168.33.12#53(192.168.33.12) > > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > > ;; MSG SIZE rcvd: 54 > > > > [root@myhost data]# dig internet-dns1.state.ma.us +trace > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > +trace > > ;; global options: +cmd > > . 516485 IN NS c.root-servers.net. > > . 516485 IN NS e.root-servers.net. > > . 516485 IN NS f.root-servers.net. > > . 516485 IN NS l.root-servers.net. > > . 516485 IN NS m.root-servers.net. > > . 516485 IN NS d.root-servers.net. > > . 516485 IN NS g.root-servers.net. > > . 516485 IN NS k.root-servers.net. > > . 516485 IN NS b.root-servers.net. > > . 516485 IN NS h.root-servers.net. > > . 516485 IN NS a.root-servers.net. > > . 516485 IN NS i.root-servers.net. > > . 516485 IN NS j.root-servers.net. > > . 516485 IN RRSIG NS 8 0 518400 > 202103 2021020922 42351 . > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== > > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms > > > > us. 172800 IN NS a.cctld.us. > > us. 172800 IN NS b.cctld.us. > > us. 172800 IN NS c.cctld.us. > > us. 172800 IN NS e.cctld.us. > > us. 172800 IN NS f.cctld.us. > > us. 172800 IN NS k.cctld.us. > > us. 86400 IN DS 21364 8 1 > 260D0461242BCF8F05473A08B05ED01E6FA59B9C > > us. 86400 IN DS 21364 8 2 > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 > > us. 86400 IN RRSIG DS 8 1 86400 202103 > 2021020922 42351 . > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== > > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms > > > > state.ma.us.7200IN NS internet-dns3.state.ma.us. > > state.ma.us.7200IN NS internet-dns1.state.ma.us. > > state.ma.us.7200IN NS internet-dns2.state.ma.us. > > state.ma.us.3600IN DS 47628 7 2 > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 > > state.ma.us.3600IN DS 41388 7 1 > 36D899932AF794EADD671161515E48FE829BB7FE > > state.ma.us.
Re: Bind 9.11 serving up false answers for a single domain.
Thanks Mark. However, the traceroute to the hostnamed failed for the same reason. Please note: [root@myhost data]# dig internet-dns1.state.ma.us ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;internet-dns1.state.ma.us. IN A ;; Query time: 1263 msec ;; SERVER: 192.168.33.12#53(192.168.33.12) ;; WHEN: Tue Feb 09 22:34:15 EST 2021 ;; MSG SIZE rcvd: 54 [root@myhost data]# dig internet-dns1.state.ma.us +trace ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us +trace ;; global options: +cmd . 516485 IN NS c.root-servers.net. . 516485 IN NS e.root-servers.net. . 516485 IN NS f.root-servers.net. . 516485 IN NS l.root-servers.net. . 516485 IN NS m.root-servers.net. . 516485 IN NS d.root-servers.net. . 516485 IN NS g.root-servers.net. . 516485 IN NS k.root-servers.net. . 516485 IN NS b.root-servers.net. . 516485 IN NS h.root-servers.net. . 516485 IN NS a.root-servers.net. . 516485 IN NS i.root-servers.net. . 516485 IN NS j.root-servers.net. . 516485 IN RRSIG NS 8 0 518400 202103 2021020922 42351 . QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms us. 172800 IN NS a.cctld.us. us. 172800 IN NS b.cctld.us. us. 172800 IN NS c.cctld.us. us. 172800 IN NS e.cctld.us. us. 172800 IN NS f.cctld.us. us. 172800 IN NS k.cctld.us. us. 86400 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 86400 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 us. 86400 IN RRSIG DS 8 1 86400 202103 2021020922 42351 . rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms state.ma.us.7200IN NS internet-dns3.state.ma.us. state.ma.us.7200IN NS internet-dns1.state.ma.us. state.ma.us.7200IN NS internet-dns2.state.ma.us. state.ma.us.3600IN DS 47628 7 2 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 state.ma.us.3600IN DS 41388 7 1 36D899932AF794EADD671161515E48FE829BB7FE state.ma.us.3600IN DS 41388 7 2 BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 state.ma.us.3600IN DS 47628 7 1 485E0EE2F7C08FCE51D1E284321242930274833A state.ma.us.3600IN RRSIG DS 8 3 3600 20210307200856 20210205191212 53985 us. O8KqBHzlZsDqrZi0NQO4JEiN0b8j04/Lb8W2uVz5PyrAat1VgZKQ3Ws6 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA== couldn't get address for 'internet-dns3.state.ma.us': not found couldn't get address for 'internet-dns1.state.ma.us': not found couldn't get address for 'internet-dns2.state.ma.us': not found dig: couldn't get address for 'internet-dns3.state.ma.us': no more [root@myhost data]# On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews wrote: > Well you could try tracing the addresses of the nameservers for which > there where errors reported. It could be as simple as a routing issue > between you and these servers. > > > On 10 Feb 2021, at 13:25, sami's strat wrote: > > > > couldn't get address for 'internet-dns1.state.ma.us': not
Re: Bind 9.11 serving up false answers for a single domain.
Well you could try tracing the addresses of the nameservers for which there where errors reported. It could be as simple as a routing issue between you and these servers. > On 10 Feb 2021, at 13:25, sami's strat wrote: > > couldn't get address for 'internet-dns1.state.ma.us': not found > couldn't get address for 'internet-dns3.state.ma.us': not found > couldn't get address for 'internet-dns2.state.ma.us': not found > dig: couldn't get address for 'internet-dns1.state.ma.us': no more -- 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
