Re: Bind 9.11 serving up false answers for a single domain. (OT)

[Ondřej Surý]

> 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)

[Mark Elkins]

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 guidance on what to do since what you 
find in the

Re: Bind 9.11 serving up false answers for a single domain. (OT)

[Stuart@registry.godaddy]

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, 2021 11:54 AM
To: Mark Andrews

Re: Bind 9.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

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)

[John W. Blue via bind-users]

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  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  
wrote:

Re: Bind 9.11 serving up false answers for a single domain. (OT)

[Stuart@registry.godaddy]

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  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  
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:
> ;; ->>HE

RE: Bind 9.11 serving up false answers for a single domain. (OT)

[John W. Blue via bind-users]

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  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  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://intern

Re: Bind 9.11 serving up false answers for a single domain. (OT)

[Stuart@registry.godaddy]

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  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  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.
> .                       516485  IN      NS      http://k.root-servers.net.
> .                       516485  IN      NS      http://b.root-servers.net.
> .                       516485  IN      NS      http://h.root-servers.ne

RE: Bind 9.11 serving up false answers for a single domain.

[John W. Blue via bind-users]

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’ 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 
> 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
>
> ; <<>> 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

Re: Trying again on SERVFAIL

[J Doe]

On 2021-02-10 3:05 a.m., Alessandro Vesely wrote:

Hi Havard,







That's what I've been doing.  For an incoming message, a temporary 
failure means replying a 4xx code.  The sender keeps the message in its 
queue, and eventually gives up.  Once upon a time, MTAs used to retry 
sending for five days.  Nowadays, several servers don't let queued 
messages grow older than one day.


In the most severe case, a failed DKIM signature might entail a reject.  
So the best course of action seems to be to reserve temporary failures 
to this case.


Still, being able to differentiate a local network congestion from a 
remote bad configuration would help.



Best
Ale


Hi Ale and list,

This isn't an answer to your original question, but I was curious about 
something you mentioned near the end of your message, where you wrote: 
"Once upon a time . . . Nowadays, several servers don't let queued 
messages grow older than one day".


Out of curiosity, what servers have you encountered that no longer use 
the five day cutoff ?


Thanks,

- J
___
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.

[Mark Andrews]

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.
>> > state.

Re: Bind 9.11 serving up false answers for a single domain.

[sami's strat]

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: Forward zone does not work when allow recursive is restrictive

[Frédéric Lochon]

This is very similar to what I wanted to do some time ago, but concluded 
this is not possible with bind.


But, I've modified bind in order to be able to do that anyway.
The trick was to use a "static-stub" zone with a small modification in 
bind code.


In my bind-9.16.6, I modified file query.c to look like that:

lib/ns/query.c


/*
 * Non recursive query to a static-stub zone is prohibited; its
 * zone content is not public data, but a part of local 
configuration

 * and should not be disclosed.
 */
    /*if (dns_zone_gettype(zone) == dns_zone_staticstub &&
    !RECURSIONOK(client)) {
    return (DNS_R_REFUSED);
    }*/
    if (dns_zone_gettype(zone) == dns_zone_staticstub)
    client->query.attributes |= NS_QUERYATTR_RECURSIONOK;



One "if" was commented to remove the check on recursion.
One "if" was added to "force" recursion.

With this modification, I turned bind to some kind of proxy for a sub-zone.
I don't really know if there are some nasty side effects, but in my case 
this is not a real problem because I don't normally use static-stub 
zones excepted for one very specific usage.


Maybe some bind expert would like to comment on this.

Frédéric Lochon.

Le 09/02/2021 à 22:44, Sebastian Neumann a écrit :

Hey there,

I am having an issue forwarding DNS queries and was hoping, that one 
of you might be able to help me:


I have the following setup:

DNS-Server reachable from the internet, is authoritative for zone foo.com
DNS-Server reachable only locally, should be authoritative for zone 
test.lab.foo.com

What I try to achieve:

When a DNS query from the outside world reaches the first DNS server 
for a record belonging to the zone test.lab.foo.com, I want it to make 
a recursive request to the second DNS server and then forward the records.


I explicitly don't want to do zone transfers or make the second DNS 
server reachable from the internet.


my configuration looks like this: (I only copied the [what I think] 
important parts to here, as all the Config would be a few hundret 
lines (because of split view and many zones)


On the first DNS-Server

options {
allow-recursion {
localnets;
localhost;
internal;
my-datacenter;
mc-office;
};
};

zone "test.lab.foo.com" {
forward only;
forwarders {
;
};
type forward;
};

zone "foo.com" {
file "/etc/bind/zones/foo.com.zone";
type master;
};
My issue:

When I am in a local network, that is whitelisted in the 
allow-recursion block, then it works as expected. When I try the DNS 
lookup from the internet, then i get a NOERROR with an empty response 
back.


During debugging, I adjusted the allow-recursion list and added any to 
it. Then it was working. But I don't want my DNS server to allow any 
kind of recursion. I actually only want "outside" lookups for this one 
specific zones to be recursive.


How can I set something like allow-recursion for just one zone?

Thanks a lot already
___
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

NEW on migrating DNSSEC config

[Skip to end for some notes on this process and why it was difficult for me.]

Just want to double check this before I set off on the next steps in this 
process, now that the test domain is all setup and everyone is happy and I know 
where things fell apart in the testing. Hopefully this helps someone in the 
future. Or future me.

Given:
#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
   keys {
  ksk key-directory lifetime unlimited algorithm 7 2048;
  zsk key-directory lifetime P60D algorithm 7 1024 ;
   };
};

zone "example.com" { 
type primary; 
file "example.com"; 
dnssec-policy alg13-ksk-unlimited-zsk-60day; 
allow-update { key "rndc-key";
}; 
};
#v-

I tell bind to sign the zone (or restart bind) and then run

 # dnssec-dsfromkey -a SHA256 /path/to/alg-13.key
 # dsnssec-verify -zI text -o example.com /path/to/signed/zone-file

Add the new key ID and digest to the registrar's DS and sit back until the 
alg-7 keys are no longer attached to the zone.

If example.com currently is using alg-7 this configuration will, as I 
understand it

   1) add alg-13 keys to the domain
   2) rolloff the alg-7 keys in (less than?) 60 days 
   3) after 61+ days I can remove the kay and private files
  for the alg-7 files

If that is correct, once all the zones have moved to alg-13 can I then 
eliminate the dnssec-policy block in the named.conf and set each zone to 
'dnssec-policy default;'?



Notes:
The main thing that caused my problems was not verifying against the SIGNED 
zone file, which led to a lot of wasted effort. This was the biggest cause of 
delays and pain, as it turns out, since it appears my first forays were 
entirely successful, and the verify errors were all based on this mistake.

When I first setup DNNSEC years ago the zone files remained untouched other 
than adding the keys as $INCLUDE statements and new zone.signed files were 
created using the key files that were on the $INCLUDE lines in the zone files.

Second, though rather minor, 
 suggested running 
`rndc signing -list` but that returns an error "zone uses dnssec-policy, use 
rndc dnssec command instead". This was not in itself a problem, but it sent me 
off trying to find out why the command was failing, assuming I was doing 
something wrong since it follows in the above link from setting up dnssec.

And, of course, searching for information on bind and dnssec returns a lot of 
things that are very old and out of date. A lot of them revolving around bind 
9.7.x.

Third, I needed to go kick the secondary DNS server.

-- 
I hear hurricanes a-blowing, I know the end is coming soon. I fear
rivers over-flowing. I hear the voice of rage and ruin.

___
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: Trying again on SERVFAIL

[Alessandro Vesely]

Hi Havard,

thanks for your reply.

On Tue 09/Feb/2021 18:15:43 +0100 Havard Eidnes wrote:

is there a way to know that a query has already been tried a few
minutes ago, and failed?


 From whose perspective?

A well-behaved application could remember it asked the same query
a short while ago, of course, but that's up to the application.



For an application, caching queries feels like stealing the resolver's job.



Or is the perspective that of a recursive resolver?  As far as I
remember, BIND used as a recursive resolver will "cache" this
knowledge, but I'm not entirely certain for how long, since it
can't use the method from an NXDOMAIN reply which includes the
SOA record (and uses the re-purposed "minimum" field for the TTL
for the negative cache entry).



I too recall that NXDOMAIN can be cached for a while.  I'd guess some kinds of 
failures are also cached.




It happens seldomly, but sometimes the DKIM mail filter gets a
SERVFAIL when it tries to authenticate an incoming message.
SERVFAIL occurs when DNSSEC check fails.


...or when none of the name servers for the containing zone
responds with an answer.  I.e. it's not *just* DNSSEC failure
which can trigger SERVFAIL.



Yes, of course.  Yet, however sporadic, DNSSEC failure seems to be the most 
frequent case.




Trying again is useless, it has to be treated as a permanent
error.


Well, now...  Basically nothing in the DNS is permanent, because
it is not completely static; hence most information in the DNS
has a TTL attached to it.  So the question then becomes how an
application, say a mail server should treat SERVFAIL.  It may
very well be that the "maximum retry time" of the mail server is
far longer than any of the TTLs for the pieces of DNS data that
you could not look up, so it may be appropriate to treat SERVFAIL
as a signal to "re-queue the message and try again in 30
minutes", so in essence converting SERVFAIL into a "temporary
failure" in the context of the mail server.



That's what I've been doing.  For an incoming message, a temporary failure 
means replying a 4xx code.  The sender keeps the message in its queue, and 
eventually gives up.  Once upon a time, MTAs used to retry sending for five 
days.  Nowadays, several servers don't let queued messages grow older than one day.


In the most severe case, a failed DKIM signature might entail a reject.  So the 
best course of action seems to be to reserve temporary failures to this case.


Still, being able to differentiate a local network congestion from a remote bad 
configuration would help.



Best
Ale
--


















___
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