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/
