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.