DNSSEC & WIldcards

Fri Mar 15 17:33:19 UTC 2024

Dennis Burgess via NANOG <nanog at nanog.org> writes:

> So have *.app.linktechs.net that I have been trying to get to work, we
> have DNSSEC on this, and its failing, but cannot for the life of me
> understand why.  I think it may have something to do with proving it
> exists as a wildcard, but any DNSSEC experts want to take a stab at it
> ?

Not an expert, but Google knows the answer (as always :-)

bjorn at miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline @8.8.8.8

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65184
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; EDE: 10 (RRSIGs Missing): (For _acme-challenge.app.linktechs.net/nsec)
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; Query time: 156 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 15 18:26:16 CET 2024
;; MSG SIZE  rcvd: 98

And they're right.  Your server includes the epected NSEC record, but
leaves out the associated RRSIG.  Compare this to the
https://datatracker.ietf.org/doc/html/rfc7129#section-5.3 example:

bjorn at miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline @139.60.210.20 

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline @139.60.210.20
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11828
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
                                20240427232616 20240313222616 37041 linktechs.net.
                                NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
                                oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
                                grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS
                                Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1
                                fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo
                                iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW
                                s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ
                                eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== )
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
                                20240427232616 20240313222616 11340 linktechs.net.
                                Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg
                                wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P
                                XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT
                                9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX
                                0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI
                                H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3
                                MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL
                                gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== )

;; AUTHORITY SECTION:
_acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG NSEC

;; Query time: 120 msec
;; SERVER: 139.60.210.20#53(139.60.210.20) (UDP)
;; WHEN: Fri Mar 15 18:27:13 CET 2024
;; MSG SIZE  rcvd: 724

Lots of resolvers will probably just look up that NSEC, get the RRSIG
and be happy with that.  But your problem is that there always will be a
number of resolvers not doing that.  So you get arbitrary failures.

I believe there are so many examples of really bad fallout due to
wildcards combined with DNSSEC that it's advisable to stay away. Do one
or the other.  Not both.

Bjørn