DANE plus wildcard record

[Viktor Dukhovni]

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.

-- 
	Viktor.