DNSSEC responses for im TLD broken

dig ds im @1.1.1.1 +dnssec should return proof of nonexistence of DS record for the im TLD. Instead it returns something else that I’m having trouble deciphering, but that looks like an unrelated proof of nxdomain for something else. This makes the entire im TLD inaccessible using 1.1.1.1 as upstream nameserver if one is performing DNSSEC validation (everything is ServFail).

Hi! Sorry about the issues, can you post a dig response? (And some troubleshooting info as per Have problems with 1.1.1.1? *Read Me First* - #3)

At the moment it’s not happening anymore; I see the correct result with the NSEC record for “im.” proving nonexistence of DS record. I closed the terminal with the bad response assuming it would be reproducible, so I don’t have my original, but I got a copy from a Libera #dns user who’d confirmed the problem with me before posting this report. Here it is:

$ dig +dnssec im ds @one.one.one.one

; <<>> DiG 9.17.17-2+ubuntu20.04.1+isc+1-Ubuntu <<>> +dnssec im ds @one.one.one.one
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64209
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION: 
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:  
;im.                            IN      DS

;; AUTHORITY SECTION: 
.                       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021091301 1800 900 604800 86400
.                       86400   IN      RRSIG   SOA 8 0 86400 20210926170000 20210913160000 26838 . ECZd1U1A8IiQiiXlj/z4yAc60ihxKE45wENl8ayZrGCRYQ0MBOwMY4dj 3FKPVA1SyVJiY4CjWPh+RjtSFlKRPaQ7rVeM3t3tMr0zqceFMuB+3XOI yTYLdlMVsgH67m3TW7iczXR6SbVZshsp7S6ERsb+RhfBLz1WNNFLxixS YzVgHuwZxuWrBYO3ji1e7fOHLYU47WzJ+JUKfb5zumdw7CB6sGSNHZsv n5p2D2k+frBqfGUdGPGH3NnO8L/m5TUgTPHT831l7Sp6SQR/4BNfN1RP C90yWbQTnmGJ8o4CZals4x+iu/GbRgUcMsMUKUPktnBm3XNUU9upGpR0 y3jG/g==
.                       86400   IN      RRSIG   NSEC 8 0 86400 20210926170000 20210913160000 26838 . IFtklbi+PNTJ5OGBHsABQAUPecuCUaAWt+xHJTbT0GYgOwPsix5EYaRZ rUTFa1WH0j8B3kHciP5EX3gHQkHvkMfOd3UZ5NEXXPqZ8r5wNiEgDwHj QsiovXaEZasbgHyUghPJsdnBjU62KJpihTnP3wmykPE+e+nWiX1hc1c/ HyHsHpWR68dBNJKs0SkJFN9XyEJaHtdrWIV3qDv3wOoVqT94TOUX7ik6 Vsvc3cc72IILj1Edn5toUwkPle6npp+jw1pZHdX2VHKtMTM1wE9lagR6 T0uwZW2jJBJYBDjOAMTcgQteRBkoZE4NO+CRPnbfUdcyU2f2xTz4NEGV qwCfAQ==
.                       86400   IN      NSEC    aaa. NS SOA RRSIG NSEC DNSKEY

;; Query time: 3 msec 
;; SERVER: 2606:4700:4700::1111#53(one.one.one.one) (UDP)
;; WHEN: Mon Sep 13 21:16:38 UTC 2021
;; MSG SIZE  rcvd: 703

Ok no problem, I can take a look. Can you post dig +short CHAOS TXT id.server @1.1.1.1 response to see which PoP are you connected to?

For me, “IAD”. I’m not sure if that’s the same as for the source of the above dig log, but I experienced the problem from here as well.

This was a problem with a partial rollout of a more aggressive root caching that we didn’t catch in tests, again sorry about the issues!

Thanks for looking into it and taking the time to give an explanation. That makes me comfortable switching back to 1.1.1.1 as my upstream again for now.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.