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