I think getting rid of SHA1 DS (DS type 1) records would be a reasonable
thing to do. They are weaker than SHA256 DS (DS type 2) records.
Generally, in life, making things simpler is a good idea and I believe
that applies here too.
.COM only provides DS type 2 records in the root so if there were
fundamental problems - we would have heard by now.
@Stuart - So do any delegations in the root zone only have SHA1 DS records?
On 2/11/21 8:01 AM, Stuart@registry.godaddy wrote:
It's one of those old compatibility things.
A quick bit of analysis of the root zone:
1,370 delegations with DS records
697 SHA1 DS records
1,519 SHA2 DS records
Yes, these numbers don't add up; there are some double and triple DS record
sets in there.
So the US zone is by no means alone in keeping it around (at least 27 other
countries similarly have them).
I'm sure that in the not-too-distant future, they'll be phased out, but for now
we don't have that as an high priority piece of work.
Stuart
On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users"
<bind-users-boun...@lists.isc.org on behalf of bind-users@lists.isc.org> wrote:
Notice: This email is from an external sender.
So out of curiosity why does the us tld have a SHA1 DS in root? Should be
an easy thing to tidy up, eh?
John
-----Original Message-----
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.
Stuart
On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users"
<bind-users-boun...@lists.isc.org on behalf of bind-users@lists.isc.org> wrote:
Notice: This email is from an external sender.
Well .. as best as I can tell .. the us tld does has a SHA1 DS record:
;; QUESTION SECTION:
;us. IN DS
;; ANSWER SECTION:
us. 50882 IN DS 21364 8 1
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882 IN DS 21364 8 2
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
Right?
In checking other tld's looks like it is a mixed bag .. some do ..
some don’t.
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com. 78577 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-----Original Message-----
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
(OT)
<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 <bind-users-boun...@lists.isc.org> on behalf of "John W. Blue via
bind-users" <bind-users@lists.isc.org> Reply to: "John W. Blue" <john.b...@rrcic.com>
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users <bind-users@lists.isc.org>
Subject: RE: Bind 9.11 serving up false answers for a single domain.
Notice: This email is from an external sender.
Three words: tcpdump and wireshark
It is like peanut and jelly .. hall and oates .. salt and pepper ..
ebb and flow .. pen and paper .. I could go on but …
Know them. Love them. They are your newest best friends.
<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:bind-users-boun...@lists.isc.org] On Behalf
Of sami's strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
Thank you all for responding. One final query about this. I'm seeing
this issue on my production servers at work. Yet, when I run the same queries
at home, I don't see those failed queries. I actually flushed DNS cache,
cleared Linux O/S cache, and even bounced my personal DNS server trying to
reproduce the issue. But I could not.
TIA
On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org>
wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you
the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us
@<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:sami.st...@gmail.com>
wrote:
>
> Thanks Mark.
>
> However, the traceroute to the hostnamed failed for the same reason.
Please note:
>
> [root@myhost data]# dig http://internet-dns1.state.ma.us
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
> http://internet-dns1.state.ma.us ;; global options: +cmd ;; Got
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 ;; flags:
> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;http://internet-dns1.state.ma.us. IN A
>
> ;; Query time: 1263 msec
> ;; SERVER: 192.168.33.12#53(192.168.33.12) ;; WHEN: Tue Feb 09
> 22:34:15 EST 2021 ;; MSG SIZE rcvd: 54
>
> [root@myhost data]# dig http://internet-dns1.state.ma.us +trace
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
> http://internet-dns1.state.ma.us +trace ;; global options: +cmd .
> 516485 IN NS http://c.root-servers.net.
> . 516485 IN NS
http://e.root-servers.net.
> . 516485 IN NS
http://f.root-servers.net.
> . 516485 IN NS
http://l.root-servers.net.
> . 516485 IN NS
http://m.root-servers.net.
> . 516485 IN NS
http://d.root-servers.net.
> . 516485 IN NS
http://g.root-servers.net.
> . 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:ma...@isc.org>
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:sami.st...@gmail.com> 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:ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
