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

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

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

Stuart@registry.godaddy
<slightly-pointless-comment-in-defence-of-us-zone>

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 <[hidden email]> on behalf of "John W. Blue via bind-users" <[hidden email]>
Reply to: "John W. Blue" <[hidden email]>
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users <[hidden email]>
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.
 
<grin>
 
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 <interface eg eth0> -s 65535 -w <filename.pcap>
 
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:[hidden email]] 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:[hidden email]> 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 @<address>’ 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:[hidden email]> 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.net.
> .                       516485  IN      NS      http://a.root-servers.net.
> .                       516485  IN      NS      http://i.root-servers.net.
> .                       516485  IN      NS      http://j.root-servers.net.
> .                       516485  IN      RRSIG   NS 8 0 518400 20210222230000 20210209220000 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      http://a.cctld.us.
> us.                     172800  IN      NS      http://b.cctld.us.
> us.                     172800  IN      NS      http://c.cctld.us.
> us.                     172800  IN      NS      http://e.cctld.us.
> us.                     172800  IN      NS      http://f.cctld.us.
> us.                     172800  IN      NS      http://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 20210222230000 20210209220000 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(http://d.root-servers.net) in 4 ms

> http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
> http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
> http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
> http://state.ma.us.            3600    IN      DS      47628 7 2 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
> http://state.ma.us.            3600    IN      DS      41388 7 1 36D899932AF794EADD671161515E48FE829BB7FE
> http://state.ma.us.            3600    IN      DS      41388 7 2 BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
> http://state.ma.us.            3600    IN      DS      47628 7 1 485E0EE2F7C08FCE51D1E284321242930274833A
> http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
> couldn't get address for 'http://internet-dns1.state.ma.us': not found
> couldn't get address for 'http://internet-dns2.state.ma.us': not found
> dig: couldn't get address for 'http://internet-dns3.state.ma.us': no more
> [root@myhost data]#
>
> On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews <mailto:[hidden email]> 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 <mailto:[hidden email]> wrote:
> >
> > couldn't get address for 'http://internet-dns1.state.ma.us': not found
> > couldn't get address for 'http://internet-dns3.state.ma.us': not found
> > couldn't get address for 'http://internet-dns2.state.ma.us': not found
> > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no more
>
> Yet, I do this on my personal computer at home, and it works without an issue.
>
> Any other thoughts?  TIA

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list
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: [hidden email] [mailto:[hidden email]]
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)

<slightly-pointless-comment-in-defence-of-us-zone>

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 <[hidden email]> on behalf of "John W. Blue via bind-users" <[hidden email]> Reply to: "John W. Blue" <[hidden email]>
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users <[hidden email]>
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.
 
<grin>
 
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 <interface eg eth0> -s 65535 -w <filename.pcap>
 
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:[hidden email]] 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:[hidden email]> 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 @<address>’ 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:[hidden email]> 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.net.
> .                       516485  IN      NS      http://a.root-servers.net.
> .                       516485  IN      NS      http://i.root-servers.net.
> .                       516485  IN      NS      http://j.root-servers.net.
> .                       516485  IN      RRSIG   NS 8 0 518400
> 20210222230000 20210209220000 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      http://a.cctld.us.
> us.                     172800  IN      NS      http://b.cctld.us.
> us.                     172800  IN      NS      http://c.cctld.us.
> us.                     172800  IN      NS      http://e.cctld.us.
> us.                     172800  IN      NS      http://f.cctld.us.
> us.                     172800  IN      NS      http://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 20210222230000 20210209220000
> 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(http://d.root-servers.net) in 4
> ms

> http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
> http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
> http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
> http://state.ma.us.            3600    IN      DS      47628 7 2
> 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
> http://state.ma.us.            3600    IN      DS      41388 7 1
> 36D899932AF794EADD671161515E48FE829BB7FE
> http://state.ma.us.            3600    IN      DS      41388 7 2
> BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
> http://state.ma.us.            3600    IN      DS      47628 7 1
> 485E0EE2F7C08FCE51D1E284321242930274833A
> http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
> couldn't get address for 'http://internet-dns1.state.ma.us': not found
> couldn't get address for 'http://internet-dns2.state.ma.us': not found
> dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
> more [root@myhost data]#
>
> On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews <mailto:[hidden email]> 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 <mailto:[hidden email]> wrote:
> >
> > couldn't get address for 'http://internet-dns1.state.ma.us': not
> > found couldn't get address for 'http://internet-dns3.state.ma.us': 
> > not found couldn't get address for
> > 'http://internet-dns2.state.ma.us': not found
> > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
> > more
>
> Yet, I do this on my personal computer at home, and it works without an issue.
>
> Any other thoughts?  TIA

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind 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" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [mailto:[hidden email]]
    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)

    <slightly-pointless-comment-in-defence-of-us-zone>

    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 <[hidden email]> on behalf of "John W. Blue via bind-users" <[hidden email]> Reply to: "John W. Blue" <[hidden email]>
    Date: Thursday, 11 February 2021 at 9:21 am
    To: bind-users <[hidden email]>
    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.

    <grin>

    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 <interface eg eth0> -s 65535 -w <filename.pcap>

    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:[hidden email]] 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:[hidden email]> 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 @<address>’ 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:[hidden email]> 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.net.
    > .                       516485  IN      NS      http://a.root-servers.net.
    > .                       516485  IN      NS      http://i.root-servers.net.
    > .                       516485  IN      NS      http://j.root-servers.net.
    > .                       516485  IN      RRSIG   NS 8 0 518400
    > 20210222230000 20210209220000 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      http://a.cctld.us.
    > us.                     172800  IN      NS      http://b.cctld.us.
    > us.                     172800  IN      NS      http://c.cctld.us.
    > us.                     172800  IN      NS      http://e.cctld.us.
    > us.                     172800  IN      NS      http://f.cctld.us.
    > us.                     172800  IN      NS      http://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 20210222230000 20210209220000
    > 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(http://d.root-servers.net) in 4
    > ms
    >
    > http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
    > http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
    > http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
    > http://state.ma.us.            3600    IN      DS      47628 7 2
    > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
    > http://state.ma.us.            3600    IN      DS      41388 7 1
    > 36D899932AF794EADD671161515E48FE829BB7FE
    > http://state.ma.us.            3600    IN      DS      41388 7 2
    > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
    > http://state.ma.us.            3600    IN      DS      47628 7 1
    > 485E0EE2F7C08FCE51D1E284321242930274833A
    > http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
    > couldn't get address for 'http://internet-dns1.state.ma.us': not found
    > couldn't get address for 'http://internet-dns2.state.ma.us': not found
    > dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
    > more [root@myhost data]#
    >
    > On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews <mailto:[hidden email]> 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 <mailto:[hidden email]> wrote:
    > >
    > > couldn't get address for 'http://internet-dns1.state.ma.us': not
    > > found couldn't get address for 'http://internet-dns3.state.ma.us':
    > > not found couldn't get address for
    > > 'http://internet-dns2.state.ma.us': not found
    > > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
    > > more
    >
    > Yet, I do this on my personal computer at home, and it works without an issue.
    >
    > Any other thoughts?  TIA

    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    [hidden email]
    https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bind-Users forum mailing list
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: [hidden email] [mailto:[hidden email]]
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" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [mailto:[hidden email]]
    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)

    <slightly-pointless-comment-in-defence-of-us-zone>

    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 <[hidden email]> on behalf of "John W. Blue via bind-users" <[hidden email]> Reply to: "John W. Blue" <[hidden email]>
    Date: Thursday, 11 February 2021 at 9:21 am
    To: bind-users <[hidden email]>
    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.

    <grin>

    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 <interface eg eth0> -s 65535 -w <filename.pcap>

    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:[hidden email]] 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:[hidden email]> 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 @<address>’ 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:[hidden email]> 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.net.
    > .                       516485  IN      NS      http://a.root-servers.net.
    > .                       516485  IN      NS      http://i.root-servers.net.
    > .                       516485  IN      NS      http://j.root-servers.net.
    > .                       516485  IN      RRSIG   NS 8 0 518400
    > 20210222230000 20210209220000 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      http://a.cctld.us.
    > us.                     172800  IN      NS      http://b.cctld.us.
    > us.                     172800  IN      NS      http://c.cctld.us.
    > us.                     172800  IN      NS      http://e.cctld.us.
    > us.                     172800  IN      NS      http://f.cctld.us.
    > us.                     172800  IN      NS      http://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 20210222230000 20210209220000
    > 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(http://d.root-servers.net) in 4
    > ms
    >
    > http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
    > http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
    > http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
    > http://state.ma.us.            3600    IN      DS      47628 7 2
    > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
    > http://state.ma.us.            3600    IN      DS      41388 7 1
    > 36D899932AF794EADD671161515E48FE829BB7FE
    > http://state.ma.us.            3600    IN      DS      41388 7 2
    > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
    > http://state.ma.us.            3600    IN      DS      47628 7 1
    > 485E0EE2F7C08FCE51D1E284321242930274833A
    > http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
    > couldn't get address for 'http://internet-dns1.state.ma.us': not found
    > couldn't get address for 'http://internet-dns2.state.ma.us': not found
    > dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
    > more [root@myhost data]#
    >
    > On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews <mailto:[hidden email]> 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 <mailto:[hidden email]> wrote:
    > >
    > > couldn't get address for 'http://internet-dns1.state.ma.us': not
    > > found couldn't get address for 'http://internet-dns3.state.ma.us':
    > > not found couldn't get address for
    > > 'http://internet-dns2.state.ma.us': not found
    > > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
    > > more
    >
    > Yet, I do this on my personal computer at home, and it works without an issue.
    >
    > Any other thoughts?  TIA

    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    [hidden email]
    https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind 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" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [mailto:[hidden email]]
    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" <[hidden email] on behalf of [hidden email]> 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: [hidden email] [mailto:[hidden email]]
        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)

        <slightly-pointless-comment-in-defence-of-us-zone>

        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 <[hidden email]> on behalf of "John W. Blue via bind-users" <[hidden email]> Reply to: "John W. Blue" <[hidden email]>
        Date: Thursday, 11 February 2021 at 9:21 am
        To: bind-users <[hidden email]>
        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.

        <grin>

        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 <interface eg eth0> -s 65535 -w <filename.pcap>

        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:[hidden email]] 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:[hidden email]> 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 @<address>’ 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:[hidden email]> 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.net.
        > .                       516485  IN      NS      http://a.root-servers.net.
        > .                       516485  IN      NS      http://i.root-servers.net.
        > .                       516485  IN      NS      http://j.root-servers.net.
        > .                       516485  IN      RRSIG   NS 8 0 518400
        > 20210222230000 20210209220000 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      http://a.cctld.us.
        > us.                     172800  IN      NS      http://b.cctld.us.
        > us.                     172800  IN      NS      http://c.cctld.us.
        > us.                     172800  IN      NS      http://e.cctld.us.
        > us.                     172800  IN      NS      http://f.cctld.us.
        > us.                     172800  IN      NS      http://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 20210222230000 20210209220000
        > 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(http://d.root-servers.net) in 4
        > ms
        >
        > http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
        > http://state.ma.us.            3600    IN      DS      47628 7 2
        > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
        > http://state.ma.us.            3600    IN      DS      41388 7 1
        > 36D899932AF794EADD671161515E48FE829BB7FE
        > http://state.ma.us.            3600    IN      DS      41388 7 2
        > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
        > http://state.ma.us.            3600    IN      DS      47628 7 1
        > 485E0EE2F7C08FCE51D1E284321242930274833A
        > http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
        > couldn't get address for 'http://internet-dns1.state.ma.us': not found
        > couldn't get address for 'http://internet-dns2.state.ma.us': not found
        > dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
        > more [root@myhost data]#
        >
        > On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews <mailto:[hidden email]> 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 <mailto:[hidden email]> wrote:
        > >
        > > couldn't get address for 'http://internet-dns1.state.ma.us': not
        > > found couldn't get address for 'http://internet-dns3.state.ma.us':
        > > not found couldn't get address for
        > > 'http://internet-dns2.state.ma.us': not found
        > > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
        > > more
        >
        > Yet, I do this on my personal computer at home, and it works without an issue.
        >
        > Any other thoughts?  TIA

        --
        Mark Andrews, ISC
        1 Seymour St., Dundas Valley, NSW 2117, Australia
        PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

        _______________________________________________
        Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

        ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


        bind-users mailing list
        [hidden email]
        https://lists.isc.org/mailman/listinfo/bind-users

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    [hidden email]
    https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Bind 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, [hidden email] 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" [hidden email] 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: [hidden email] [[hidden email]]
    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" [hidden email] 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: [hidden email] [[hidden email]]
        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)

        <slightly-pointless-comment-in-defence-of-us-zone>

        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 [hidden email] on behalf of "John W. Blue via bind-users" [hidden email] Reply to: "John W. Blue" [hidden email]
        Date: Thursday, 11 February 2021 at 9:21 am
        To: bind-users [hidden email]
        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.

        <grin>

        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 <interface eg eth0> -s 65535 -w <filename.pcap>

        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 [[hidden email]] 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 [hidden email] 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 @<address>’ 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 [hidden email] 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.net.
        > .                       516485  IN      NS      http://a.root-servers.net.
        > .                       516485  IN      NS      http://i.root-servers.net.
        > .                       516485  IN      NS      http://j.root-servers.net.
        > .                       516485  IN      RRSIG   NS 8 0 518400
        > 20210222230000 20210209220000 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      http://a.cctld.us.
        > us.                     172800  IN      NS      http://b.cctld.us.
        > us.                     172800  IN      NS      http://c.cctld.us.
        > us.                     172800  IN      NS      http://e.cctld.us.
        > us.                     172800  IN      NS      http://f.cctld.us.
        > us.                     172800  IN      NS      http://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 20210222230000 20210209220000
        > 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(http://d.root-servers.net) in 4
        > ms
        >
        > http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
        > http://state.ma.us.            3600    IN      DS      47628 7 2
        > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
        > http://state.ma.us.            3600    IN      DS      41388 7 1
        > 36D899932AF794EADD671161515E48FE829BB7FE
        > http://state.ma.us.            3600    IN      DS      41388 7 2
        > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
        > http://state.ma.us.            3600    IN      DS      47628 7 1
        > 485E0EE2F7C08FCE51D1E284321242930274833A
        > http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
        > couldn't get address for 'http://internet-dns1.state.ma.us': not found
        > couldn't get address for 'http://internet-dns2.state.ma.us': not found
        > dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
        > more [root@myhost data]#
        >
        > On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews [hidden email] 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 [hidden email] wrote:
        > >
        > > couldn't get address for 'http://internet-dns1.state.ma.us': not
        > > found couldn't get address for 'http://internet-dns3.state.ma.us':
        > > not found couldn't get address for
        > > 'http://internet-dns2.state.ma.us': not found
        > > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
        > > more
        >
        > Yet, I do this on my personal computer at home, and it works without an issue.
        >
        > Any other thoughts?  TIA

        --
        Mark Andrews, ISC
        1 Seymour St., Dundas Valley, NSW 2117, Australia
        PHONE: +61 2 9871 4742              INTERNET: [hidden email]

        _______________________________________________
        Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

        ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


        bind-users mailing list
        [hidden email]
        https://lists.isc.org/mailman/listinfo/bind-users

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    [hidden email]
    https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
--

Mark James ELKINS  -  Posix Systems - (South) Africa
[hidden email]       Tel: <a href="tel:+27826010496">+27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

Posix
          SystemsVCARD for
          MJ Elkins


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Ondřej Surý
In reply to this post by Stuart@registry.godaddy
> On 11. 2. 2021, at 7:01, [hidden email] 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)
[hidden email]



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stuart@registry.godaddy
In reply to this post by Mark Elkins
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 <[hidden email]>
Date: Thursday, 11 February 2021 at 6:42 pm
To: Stuart Browne <[hidden email]>, bind-users <[hidden email]>
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:[hidden email] 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:[hidden email]-[hidden email] 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:[hidden email] [mailto:[hidden email]]
    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:[hidden email]-[hidden email] 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:[hidden email] [mailto:[hidden email]]
        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)

        <slightly-pointless-comment-in-defence-of-us-zone>

        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:[hidden email] on behalf of "John W. Blue via bind-users" mailto:[hidden email] Reply to: "John W. Blue" mailto:[hidden email]
        Date: Thursday, 11 February 2021 at 9:21 am
        To: bind-users mailto:[hidden email]
        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.

        <grin>

        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 <interface eg eth0> -s 65535 -w <filename.pcap>

        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:[hidden email]] 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:[hidden email] 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 @<address>’ 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:[hidden email] 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.net.
        > .                       516485  IN      NS      http://a.root-servers.net.
        > .                       516485  IN      NS      http://i.root-servers.net.
        > .                       516485  IN      NS      http://j.root-servers.net.
        > .                       516485  IN      RRSIG   NS 8 0 518400
        > 20210222230000 20210209220000 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      http://a.cctld.us.
        > us.                     172800  IN      NS      http://b.cctld.us.
        > us.                     172800  IN      NS      http://c.cctld.us.
        > us.                     172800  IN      NS      http://e.cctld.us.
        > us.                     172800  IN      NS      http://f.cctld.us.
        > us.                     172800  IN      NS      http://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 20210222230000 20210209220000
        > 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(http://d.root-servers.net) in 4
        > ms
        >
        > http://state.ma.us.            7200    IN      NS      http://internet-dns3.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns1.state.ma.us.
        > http://state.ma.us.            7200    IN      NS      http://internet-dns2.state.ma.us.
        > http://state.ma.us.            3600    IN      DS      47628 7 2
        > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
        > http://state.ma.us.            3600    IN      DS      41388 7 1
        > 36D899932AF794EADD671161515E48FE829BB7FE
        > http://state.ma.us.            3600    IN      DS      41388 7 2
        > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769
        > http://state.ma.us.            3600    IN      DS      47628 7 1
        > 485E0EE2F7C08FCE51D1E284321242930274833A
        > http://state.ma.us.            3600    IN      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 'http://internet-dns3.state.ma.us': not found
        > couldn't get address for 'http://internet-dns1.state.ma.us': not found
        > couldn't get address for 'http://internet-dns2.state.ma.us': not found
        > dig: couldn't get address for 'http://internet-dns3.state.ma.us': no
        > more [root@myhost data]#
        >
        > On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews mailto:[hidden email] 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 mailto:[hidden email] wrote:
        > >
        > > couldn't get address for 'http://internet-dns1.state.ma.us': not
        > > found couldn't get address for 'http://internet-dns3.state.ma.us':
        > > not found couldn't get address for
        > > 'http://internet-dns2.state.ma.us': not found
        > > dig: couldn't get address for 'http://internet-dns1.state.ma.us': no
        > > more
        >
        > Yet, I do this on my personal computer at home, and it works without an issue.
        >
        > Any other thoughts?  TIA

        --
        Mark Andrews, ISC
        1 Seymour St., Dundas Valley, NSW 2117, Australia
        PHONE: +61 2 9871 4742              INTERNET: mailto:[hidden email]

        _______________________________________________
        Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

        ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


        bind-users mailing list
        mailto:[hidden email]
        https://lists.isc.org/mailman/listinfo/bind-users

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    mailto:[hidden email]
    https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
mailto:[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS  -  Posix Systems - (South) Africa
mailto:[hidden email]       Tel: tel:+27826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za




_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

image001.jpg (8K) Download Attachment
image002.png (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stuart@registry.godaddy
In reply to this post by Ondřej Surý
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ý" <[hidden email] on behalf of [hidden email]> wrote:

    Notice: This email is from an external sender.



    > On 11. 2. 2021, at 7:01, [hidden email] 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)
    [hidden email]



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Ondřej Surý
Thanks! That was the response I was looking for. Much appreciated!

--
Ondřej Surý (He/Him)
[hidden email]

> On 11. 2. 2021, at 9:03, [hidden email] 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ý" <[hidden email] on behalf of [hidden email]> wrote:
>
>    Notice: This email is from an external sender.
>
>
>
>> On 11. 2. 2021, at 7:01, [hidden email] 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)
>    [hidden email]
>
>
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (849 bytes) Download Attachment