DNSSEC Failures on *.kif.rocks CNAME

We have a wildcard CNAME record *.kif.rocks via DeSEC (desec.io) pointing to kif.rocks.

Querying it with dig works fine: dig @1.1.1.1 matrix.kif.rocks A:

; <<>> DiG 9.18.19 <<>> @1.1.1.1 foo.kif.rocks A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16348
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;foo.kif.rocks.			IN	A

;; ANSWER SECTION:
foo.kif.rocks.		3600	IN	CNAME	kif.rocks.
kif.rocks.		3600	IN	A	129.217.6.148

;; Query time: 21 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Jan 25 15:09:54 CET 2024
;; MSG SIZE  rcvd: 72

However, using delv @1.1.1.1 lol.kif.rocks A this fails most of the time:

;; no valid NSEC resolving 'lol.kif.rocks/A/IN': 1.1.1.1#53
;; resolution failed: no valid NSEC

Not sure what delv does differently than dig. From what I understand, it might have something to do with that the NSEC error is about a missing validation of no A record being there, which dig migh not care about because it follows the CNAME anyway, but delv does fail on that.

But it’s not just delv, I noticed the problem at all because the dnsmasq in my router was returning SERVFAILS for matrix.kif.rocks with a similar error message complaining about missing NSEC.

I’ve yet to understand any pattern on why this works when. At the time of writing, lol. seems to always fail, but worked well for a few times when I started fiddling around with it. matrix., the actually used domain I originally noticed the problem with, seems to mostly not worked but worked a few times intermittently a few minutes ago. While foo., which I’ve just started trying out, seems to be always working fine. (it’s a little later now and lol. has started failing as well, so it almost seems like it takes some time after first querying a domain until it starts failing…)

I have no clue whether that’s actually a Cloudflare problem or maybe a problem with our DNS setup, but the problem doesn seem to happen with Google’s DNS servers, it happened for friends of mine on other internet connections using delv as well, and both the DNSSEC analyzer (https://dnssec-analyzer.verisignlabs.com/lol.kif.rocks) and DNSViz are happy with our domains, so I thought I should post about it here, maybe someone has an idea.

I’m in the DUS data center region. [1.1.1.1 connection information link: https://one.one.one.one/help/#eyJpc0NmIjoiTm8iLCJpc0RvdCI6Ik5vIiwiaXNEb2giOiJObyIsInJlc29sdmVySXAtMS4xLjEuMSI6IlllcyIsInJlc29sdmVySXAtMS4wLjAuMSI6IlllcyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjExMTEiOiJZZXMiLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMDAxIjoiWWVzIiwiZGF0YWNlbnRlckxvY2F0aW9uIjoiRFVTIiwiaXNXYXJwIjoiTm8iLCJpc3BOYW1lIjoiR29vZ2xlIFNlcnZlcnMiLCJpc3BBc24iOiIxNTE2OSJ9

Hm, I cannot replicate this from my end, currently I always got fully validated.
I see DNSSEC status is okay.
Did you changed something in the meantime?

Thanks for sharing. Maybe someone else could have some feedback information in the meantime and reply.

FYI, I’m from deSEC (the DNS provider in question).

I was able to reproduce the problem a few days ago. The problem was that Cloudflare’s resolvers didn’t include the denial-of-existence (DoE) proof for the matrix owner name, as would be required in order to prove that the wildcard record is indeed applicable. The authoritative nameservers do provide the DoE, and Google Public Resolver returns them properly:

Google:

$ dig +noall +answer +auth +dnssec @8.8.8.8 matrix.kif.rocks 
matrix.kif.rocks.    828    IN    CNAME    kif.rocks.
matrix.kif.rocks.    828    IN    RRSIG    CNAME 13 2 3600 20240208000000 20240118000000 12922 kif.rocks. nKs6ivU44Wb4qG14uH7m+b/S8jeNJ2FJ8EWqXX7tinEGZRl9aHL/WVMi 4yJ+ni39o6BX+1lYuUk/0IFojAxZUg==
kif.rocks.        828    IN    A    129.217.6.148
kif.rocks.        828    IN    RRSIG    A 13 2 3600 20240208000000 20240118000000 12922 kif.rocks. DW1OGcJ0jDleTWjMwGqpYxmZ9JhI8S3DzJkUU68FvdjVGCJpZYyLWtWm 5ibI5wLTOo5aMyLk7EO3TrWRgO0TNA==
8r37upqfbl0jnp9mq1lvsmo0rgh0m5ug.kif.rocks. 0 IN NSEC3 1 0 0 - BF0RD30QQCUNLSG7UIM0Q340OGEA7DLJ CNAME RRSIG
8r37upqfbl0jnp9mq1lvsmo0rgh0m5ug.kif.rocks. 0 IN RRSIG NSEC3 13 3 300 20240208000000 20240118000000 12922 kif.rocks. 9/sabc1E383xiufFn+PiMHw+9IN8K+T+S15m+rPIl+XGr85Qy/L3iEtf uV4Gm6JVru0jK/8KUskdJc/HUeS5SA==

Cloudflare:

$ dig +noall +answer +auth +dnssec @1.1.1.1 matrix.kif.rocks 
matrix.kif.rocks.    2465    IN    CNAME    kif.rocks.
matrix.kif.rocks.    2465    IN    RRSIG    CNAME 13 2 3600 20240208000000 20240118000000 12922 kif.rocks. nKs6ivU44Wb4qG14uH7m+b/S8jeNJ2FJ8EWqXX7tinEGZRl9aHL/WVMi 4yJ+ni39o6BX+1lYuUk/0IFojAxZUg==
kif.rocks.        2914    IN    A    129.217.6.148
kif.rocks.        2914    IN    RRSIG    A 13 2 3600 20240208000000 20240118000000 12922 kif.rocks. DW1OGcJ0jDleTWjMwGqpYxmZ9JhI8S3DzJkUU68FvdjVGCJpZYyLWtWm 5ibI5wLTOo5aMyLk7EO3TrWRgO0TNA==

This seems to be a transient issue, and perhaps depending on owner name (it did not occur with matriz) or on PoP. I don’t think this can be further debugged from external.

Best,
Peter

2 Likes

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