Dennis Burgess via NANOG <nanog@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@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@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