DANE plus wildcard record

[Rob McGee]

On 2019-06-15 16:44, Viktor Dukhovni wrote:
> On Sat, Jun 15, 2019 at 12:11:29PM -0500, Rob McGee wrote:
> 
>> One of my subscribers recently signed his or her zone, and sadly, has 
>> a
>> wildcard A in that zone.
> 
> Wildcard A records are not in themselves a problem for DANE, lots
> of domains have them with no issues.  What can be a problem is

Okay, blaming this on the wildcard was my first impulse, but as I began
to dig (no pun intended, or maybe it was) deeper, I doubted it.  The
dane.sys4.de tool got a SERVFAIL, and when I checked my own named logs
I saw that the SERVFAIL was a query for DS for smtp.example.com.  Had
nothing to do with the existence of the _25.tcp.smtp.example.com. name.

> having a nameserver that omits the wildcard name from the NSEC/NSEC3
> chain, and therefore returns "bogus" denial of existence when asked
> for the TLSA records.

... and this is why named wanted to check for DS, I guess.

...
>> So Postfix is refusing to deliver, believing that there should be a
>> TLSA.  But AFAIK this user never published TLSA.
> 
> Yes, but that fact has to have a valid denial of existence proof,
> or else absence of TLSA records could be trivially spoofed, introducing
> MiTM attacks that DNSSEC is designed to prevent.

Oh, yes.  At first I wondered if there was a Postfix DANE bug here, but
indeed, refusing to deliver when getting SERVFAIL on the way to the TLSA
is the only reasonable thing to do.

Similarly, named is doing the right thing in the face of the broken NSEC
chain.

> On Sat, Jun 15, 2019 at 02:41:15PM -0500, Rob McGee wrote:
> 
>> Logs (from named) of the SERVFAIL:
>> 
>> 15-Jun-2019 18:49:00.567 lame-servers: info: broken trust chain
>> resolving '_25._tcp.smtp.example.com/TLSA/IN': 176.56.237.121#53
> 
> Finally, a data leak! :-)  That IP address, 176.56.237.121, is
> dynu.com.  They have multiple domains that have broken DoE (Denial
> of Existence), e.g.

Haha, indeed it is, glad I was able to accidentally help you to get
to the bottom of this. :)  I'm not a very good redactor.

...
> This is a case of all-too-clever broken software, that fails to
> correctly implement DNSSEC denial of existence.  Your subscriber
> needs to find a more competent DNS provider.

Gotcha.  I will pass the word along.  Thank you for the sharp eye and
the detailed explanations.
-- 
   http://rob0.nodns4.us/