Hi all, first post here. Hi Viktor and the sys4.de gang.
I host a mailing list for a free software project with DANE enabled both ways. No need for secrecy there, it's Slackbuilds.org.
One of my subscribers recently signed his or her zone, and sadly, has a wildcard A in that zone. Unfortunately at this point I do have to keep that zone name private, although offlist I'd tell it to someone I know and consider trustworthy to maintain the user's confidence.
Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I already DID tell you the zone name. :) Starts with "a" and is in com. TLD. The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA".
So Postfix is refusing to deliver, believing that there should be a TLSA. But AFAIK this user never published TLSA.
The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that. But I don't know how that feature interacts with wildcard records.
Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.
On 2019-06-15 12:11, I wrote:
One of my subscribers recently signed his or her zone, and sadly, has a wildcard A in that zone. Unfortunately at this point I do have to keep that zone name private, although offlist I'd tell it to someone I know and consider trustworthy to maintain the user's confidence.
The immediate problem has been solved with a bandaid, smtp_tls_policy_maps, with an entry:
example.com may
This overrides the global "smtp_tls_security_level = dane" setting, and I've confirmed that I can send mail to the subscriber now.
Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I already DID tell you the zone name. :) Starts with "a" and is in com. TLD. The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA".
So Postfix is refusing to deliver, believing that there should be a TLSA. But AFAIK this user never published TLSA.
The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that. But I don't know how that feature interacts with wildcard records.
Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.
I still think this is an interesting problem, perhaps a BIND problem. The user didn't set a TLSA and might have had no idea about DANE ("isn't that what Hamlet was?") and yet was unable to get mail from my DANE- enabled host.
On 2019-06-15 13:48, I wrote:
On 2019-06-15 12:11, I wrote:
Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.
I still think this is an interesting problem, perhaps a BIND problem. The user didn't set a TLSA and might have had no idea about DANE ("isn't that what Hamlet was?") and yet was unable to get mail from my DANE- enabled host.
Logs (from named) of the SERVFAIL:
15-Jun-2019 18:49:00.419 lame-servers: info: no valid RRSIG resolving 'smtp.example.com/DS/IN': 176.56.237.121#53 15-Jun-2019 18:49:00.468 lame-servers: info: no valid RRSIG resolving 'smtp.example.com/DS/IN': 45.119.209.45#53 15-Jun-2019 18:49:00.468 lame-servers: info: no valid DS resolving '_25._tcp.smtp.example.com/TLSA/IN': 45.119.209.45#53 15-Jun-2019 18:49:00.567 dnssec: info: validating _25._tcp.smtp.example.com/TLSA: bad cache hit (smtp.example.com/DS) 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
This was after "rndc flushtree example.com", so I am still not sure what the error means.
Hmm, why is it wanting DS for smtp.example.com? That's not a zone, it is only an A record in example.com.
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 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. Consider a zone containing only the zone apex (with SOA, DNSKEY, NS, MX records and associated RRSIGs) and a signed wildcard A record (with RRSIG):
; Zone apex NS/SOA/DNSKEY/... elided example.com. IN MX 0 smtp.example.com. example.com. IN A 192.0.2.1
; Wildcard A record only other node in the zone *.example.com. IN A 192.0.2.1
Its NSEC chain *should* be:
example.com. IN NSEC *.example.com. A NS SOA MX RRSIG NSEC DNSKEY *.example.com. IN NSEC example.com. A RRSIG NSEC
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 ...
The NOERROR rather than NXDOMAIN is due to the wildcard, but since it only has A records, and no TLSA records, the answer count is zero. The authority records provide the authenticated denial of existence proof. The signed NSEC record establishes the existence of the wildcard, and non-existence of "smtp.example.com" as an explicit name in the zone.
Now, consider what happens if the nameserver software or zone data is broken and omits the wildcard from NSEC chain, which now contains only the zone apex (This is a circular reference in otherwise empty zones):
$ 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 RRSIG NSEC example.com. IN RRSIG NSEC ...
We now have a contradiction. The header says "NOERROR", implying the name exists or is wildcard-synthesised, but the NSEC chain proves that only the zone apex exists, so a consistent answer would be NXDOMAIN. In this situation (and others similar in spirit if not every detail), the validating resolver returns "SERVFAIL".
This problem is somewhat more frequent with PowerDNS servers backed by a database, when the SQL database with the zone data is incorrectly populated, or the software is substantially outdated.
The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA".
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.
The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that.
The "_" is allowed in TLSA records, this is not relevant here.
But I don't know how that feature interacts with wildcard records.
Wildcard A records work as one would expect. Indeed you should be able to resolve "_25._tcp.smtp.example.com IN A ?" and get the wildcard address.
Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.
That's because dnsmasq is not doing DNSSEC validation.
On Sat, Jun 15, 2019 at 01:48:27PM -0500, Rob McGee wrote:
The immediate problem has been solved with a bandaid, smtp_tls_policy_maps, with an entry:
example.com may
Or, alternatively, in e.g. unbound:
server: domain-insecure: "example.com."
I still think this is an interesting problem, perhaps a BIND problem.
No, the issue is broken DNS for example.com.
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.
jerryscomputing.com SOA ns1.dynu.com administrator@dynu.com
When I ask the domain's nameservers for TLSA records, they all just return empty NOERROR replies (EDNS OPT record only, no SOA, no RRSIG, ...):
@ns1.dynu.com.[207.38.70.2] @ns2.dynu.com.[104.247.193.125] @ns3.dynu.com.[45.79.219.7] @ns4.dynu.com.[45.119.209.45] @ns5.dynu.com.[74.121.191.194] @ns6.dynu.com.[168.235.71.124] ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.jerryscomputing.com @... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31304 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.jerryscomputing.com. IN TLSA
While asking for an A record for the same name returns:
@ns1.dynu.com.[207.38.70.2] @ns2.dynu.com.[104.247.193.125] @ns3.dynu.com.[45.79.219.7] @ns4.dynu.com.[45.119.209.45] @ns5.dynu.com.[74.121.191.194] @ns6.dynu.com.[168.235.71.124] ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t a _25._tcp.jerryscomputing.com @... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63350 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.jerryscomputing.com. IN A _25._tcp.jerryscomputing.com. RRSIG A 13 4 90 20190617213727 20190613213727 5126 jerryscomputing.com. _25._tcp.jerryscomputing.com. A 3.13.189.185
which appears to be signed "on the fly" (ECDSA P-256, algorithm 13, is fast enough to make that practical) rather than wildcard-synthesised, because the RRSIG label count is 4 and no NSEC records were sent to justify the use of a wildcard. So this server lies about wildcards and returns synethetic records on the fly, avoiding NSEC as much as possible, but does not know how to handle non-existent RR types.
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.
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.
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.
participants (2)
-
Rob McGee -
Viktor Dukhovni