On Sat, Jun 15, 2019 at 05:44:59PM -0400, Viktor Dukhovni wrote:
The address of the MX host "smtp.example.com" is wildcard-synthesised, and the correct response for the TLSA query would be:
$ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ; _25._tcp.smtp.example.com IN TLSA ?
;; OPT PSEUDOSECTION: ; ... ;; QUESTION SECTION: ;_25._tcp.smtp.example.com. IN TLSA
example.com. IN SOA ... example.com. IN RRSIG SOA ... example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY example.com. IN RRSIG NSEC ...
Sorry, when re-reading this, I noticed that I accidentally in part edited the "should be" response while editing the wrong response and vice-versa. The *correct* NSEC record is the wildcard one:
*.example.com. IN NSEC example.com. A RRSIG NSEC *.example.com. IN RRSIG NSEC ...
The "wrong" record when the NSEC chain is incomplete is:
example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY example.com. IN RRSIG NSEC ...
as it turned out, the issue with dynu.com is somewhat different, in that they simply don't appear to do NSEC (or NSEC3) records, which means that DNSSEC-signed domains they host that don't have TLSA records, are broken.