DS record does not resolve

I have a subdomain delegated to be managed elsewhere, with NS and a DS record. When I first
set it a week or so ago it was fine, but this morning the DS record won’t resolve. The authoritative nameservers just won’t send it back. It still shows up on the dashboard, I’ve added and removed it, but it just doesn’t come back in a dig response. The NS comes back fine.
Needless to say, this breaks things. Any ideas? It is an 8 2.

  1. What domain?

  2. What subdomain?

  3. Can you share a list, perhaps a screenshot, of the record(s) you have issues with, so we can see how they appear in your Cloudflare Dashboard?

1 Like

I can see the DS record just fine, and the subdomain also seems to resolve with different resolvers, except that you don’t seem to have added any records for it yet.

If you look at the ad flag in the 2nd query, it means that DNSSEC was successfully validated.

dig dyn.dunlops.net @ignat.ns.cloudflare.com +dnssec

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> dyn.dunlops.net @ignat.ns.cloudflare.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 659
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;dyn.dunlops.net.               IN      A

;; AUTHORITY SECTION:
dyn.dunlops.net.        300     IN      NS      ns-cloud-a1.googledomains.com.
dyn.dunlops.net.        300     IN      NS      ns-cloud-a2.googledomains.com.
dyn.dunlops.net.        300     IN      NS      ns-cloud-a3.googledomains.com.
dyn.dunlops.net.        300     IN      NS      ns-cloud-a4.googledomains.com.
dyn.dunlops.net.        300     IN      DS      32566 8 2 6F1C11569B342587E4469D091923233DF810F25EB489E311F8B3FD46 7BC175DE
dyn.dunlops.net.        300     IN      RRSIG   DS 13 3 300 20231028145653 20231026125653 34505 dunlops.net. A78wyPn4EQo5fACs+72FgRKCDr0v2Go9z80soFDpPeQjWoYYpvytZFen gmTOGqPhaCilMi/TfDGPtaa3csAuDg==

;; Query time: 4 msec
;; SERVER: 2a06:98c1:50::ac40:2313#53(ignat.ns.cloudflare.com) (UDP)
;; WHEN: Fri Oct 27 15:56:53 CEST 2023
;; MSG SIZE  rcvd: 320
dig @8.8.8.8 +dnssec dyn.dunlops.net

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> @8.8.8.8 +dnssec dyn.dunlops.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19201
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;dyn.dunlops.net.               IN      A

;; AUTHORITY SECTION:
dyn.dunlops.net.        300     IN      SOA     ns-cloud-a1.googledomains.com. cloud-dns-hostmaster.google.com. 2 21600 3600 259200 300
dyn.dunlops.net.        300     IN      RRSIG   SOA 8 3 21600 20231117123234 20231026123234 33243 dyn.dunlops.net. T9YBpiHqdJIYUaNmZcimmY49i/U0t6y0UDN0LludujnD+VAqOzW5JaV9 KVLdxMQo1SL/u065F49vW/oyuwbWXfn4GuG540RSrnKFAyQjkf8Fh7zC uQd1sh1toZ7Su+34yRDeC8ICxOagTvi1tF2eIN0sk2P96VxucAsuww/h t9Y=
cf0kna8man7gn6n879o8311fhi0c7mrm.dyn.dunlops.net. 300 IN NSEC3 1 0 1 EB7BD7BD89C8FA77 GO48PFQOH9I3C2DIU4GK988MID4TSOIS NS SOA RRSIG DNSKEY NSEC3PARAM CDS
cf0kna8man7gn6n879o8311fhi0c7mrm.dyn.dunlops.net. 300 IN RRSIG NSEC3 8 4 300 20231117123234 20231026123234 33243 dyn.dunlops.net. lDqMsL3m9vJ0HsWJOBCr+TysTTvK16kAewRBmn8F5pkw2iAVe57+cQbc A2gR3IJJOxHEQyDfqfcbMVviQiiIy02+Nx/QT2o0w9UHwwG1Pqm07c43 Eww9TXUEULfcquRc34vrayUPC4BGI+4iIOE85An/60gASGkhcfS77WbL +IU=

;; Query time: 72 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Oct 27 16:09:36 CEST 2023
;; MSG SIZE  rcvd: 576

It’s the DS. You haven’t done a dig for the DS record above

Sorry, for some reason this isn’t letting me put anything more complicated than that in, thinking they are links.

The DS record itself does not resolve. This breaks DNSSEC validation for everything below.

You can clearly see the DS record in my first query.

As I mentioned, you can see in the 2nd query that the ad flag is set, which means DNSSEC is validated.

Sorry, the issue is that if you directly do a dig DS there is no response. Then if you try doing it at a recursive nameserver there is an EDNS that says it’s bogus. Try doing that and you’ll see the issue. It started happening this morning.

dig DS @ignat.NS.cloudflare.com dyn.dunlops.net

dig DS @1.1.1.1 dyn.dunlops.net

You forgot the +dnssec option there. Without it, you will not receive any DNSSEC information.

dig DS @ignat.NS.cloudflare.com dyn.dunlops.net +dnssec

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> DS @ignat.NS.cloudflare.com dyn.dunlops.net +dnssec
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33923
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
dyn.dunlops.net.        300     IN      DS      32566 8 2 6F1C11569B342587E4469D091923233DF810F25EB489E311F8B3FD46 7BC175DE
dyn.dunlops.net.        300     IN      RRSIG   DS 13 3 300 20231028154340 20231026134340 34505 dunlops.net. vrEgkHc4nznITfcI1caxMU5PTN2Z9OA3YCnTLSN2zH2HGqh51mvzIvIw IobFO7jhAu4mroOgGjxlIeOqUTyl5A==

;; Query time: 8 msec
;; SERVER: 2a06:98c1:50::ac40:2313#53(ignat.NS.cloudflare.com) (UDP)
;; WHEN: Fri Oct 27 16:43:40 CEST 2023
;; MSG SIZE  rcvd: 199

This will not work, as the DS record is only part of the authority section, not the answer section. A recursive resolver will not show that information to you.

Do you have any actual queries that you have problems with? There is no reason to directly query DS records.

No, the DS is part of the answer section. Try
delv @1.1.1.1 CNAME home.dyn.dunlops.net and you’ll see the issue.
Also try
dig DS cloudflare.com

The DS needs to be in the answer section for DNS validation to work !

See the bold paragraph:

1 Like

Hmm. I guess delv and unbound don’t follow the rfc strictly, since they are not validating this zone. Pretty sure I would have the same issue with systemd.
This is really an issue, and unfortunately I can’t transfer out for the next 2 months. The strange thing is that it was working fine until this morning.

Also dnsviz shows the issue

https://dnsviz.net/d/dyn.dunlops.net/dnssec/

Yes, I’ve seen that dnsviz, delv and verisign all show a bogus delegation. Internet.nl however shows a valid DNSSEC chain, and the public resolvers I tested (1.1.1.1 and 8.8.8.8) also confirm successful DNSSEC validation.

That is the problem with relying on non-standard behaviour (if that is actually the case): The behaviour might change at any moment.

Every other domain I can see actually responds with a DS query, including you.
While the earlier RFC’s included a MUST on this, which may be overridden by 4035, I have
to say it is problematic that this simple result for a DS query isn’t there. When I add a line I expect that line to be propagated with a simple DIG.

I am annoyed about the 60 day transfer block, otherwise I’d go immediately to somewhere else that wouldn’t be so limiting. I moved here because google domains ended, but I am seriously regretting it. I already had to do some changes because you wouldn’t allow multiple DS when one of the delegates has a CDS. All I want to do is split-horizon DNSSEC, which is really not that complicated of a situation.

Just as a followup: it looks like I can work around this, but it breaks using DNS over TLS to 8.8.8.8 and 1.1.1.1, etc. if I want to validate the dnssec myself, rather than trusting the recursive server to do it for me. unbound on my local network can do the validation step but only if it reaches out to the authoritative nameserver on unencrypted port 53 instead of trying to get it via DNS over TLS from 1.1.1.1. The interesting thing is that it then returns a cached non-authoritative DS in response to a direct query for the DS, but 1.1.1.1 returns a SERVFAIL with EDNS EDE 6 (DNSSEC bogus) since there was no NSEC response but also no DS response, 8.8.8.8 returns an EDE 12 (NSEC missing) and 9.9.9.9 returns the DS. I would have thought that cloudflare (owning 1.1.1.1) would do something to allow for recursive caching to match their own authoritative server.

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