With draft-ietf-dane-ops and draft-ietf-dane-smtp-with-dane both
now in the RFC editor queue, I'd like to bring to your attention
important related considerations for DNS operators.
When opportunistic DANE TLS clients try to determine whether TLSA
records exist for peers whose address records are found in signed
zones, lookup failures (bogus replies, SERVFAIL, timeout, ...) are
indistinguishable from an attack.
Thus nameservers for signed zones that fail to reply to TLSA queries
with either a correctly validated denial of existence (NXDOMAIN or
NOERROR && ancount == 0) or actual TLSA records will cause delays
in email delivery from a presently small, but growing list of
senders.
The most common issues to watch out for are:
* Outdated versions of PowerDNS, don't handle denial of
existence correctly, the query domain's immediate parent
also does not exist. In particular queries of the form:
_25._tcp.example.com. IN TLSA ?
fail to elicit proof that "_tcp" does not exist (which is
typically the case). The response is then "bogus", and mail
is delayed.
This currently afflicts various Neustar.biz nameservers, in
some cases appearing as nameservers for various customers.
* No response to TLSA queries, while A or AAAA queries for
same owner name yield NXDOMAIN. Often an Arbor Networks or
Infoblox server with misguided "security" enabled to filter
out queries for all but the most common RRtypes. Largest
problem domain count is at "isphuset.no".
* Mishandling of denial of existence in the presence of wildcard
records (poor handling of empty non-terminals) in djbdns with
unofficial DNSSEC patches.
* Outdated secondary servers that only NSEC RRs serving zones
that employ NSEC3 records (and thus unable to do denial of
existence correctly).
* Lastly, mostly as a curiosity, something very strange at
truman.edu, where TLSA denial of existence returns a bad
signature for the SOA record, while a query for the SOA record
itself returns the same SOA RRDATA with a valid signature
(differing only in the last 32 bits). No idea how that
happens, but they seem to like it that way (notifications
don't lead to remedial action). Compare:
_25._tcp.barracuda.truman.edu IN TLSA ?
truman.edu. SOA ns3.truman.edu. dns-alerts.truman.edu. 2053533256 3600
900 1209600 3600
truman.edu. RRSIG SOA 5 2 3600 20150911030001 20150812030001 17523
truman.edu.
xkuFFH9J6CZlo8oPGtDoDCXxD1iZdD+KkusLGJvcvqaQNClgEdaHu0VEg9Z/mqCg/wBFa4m4XCzwhNFklBiMtmn9qZQ6EyAPCjeE1UBGaspXeiYO262lWwuyLf35KkjRXxKberuoEI9rTTGy8at3xFdLNWaljsAQxCRkGwAAAlg=
truman.edu IN SOA ?
truman.edu. SOA ns3.truman.edu. dns-alerts.truman.edu. 2053533256 3600
900 1209600 3600
truman.edu. RRSIG SOA 5 2 3600 20150911030001 20150812030001 17523
truman.edu.
xkuFFH9J6CZlo8oPGtDoDCXxD1iZdD+KkusLGJvcvqaQNClgEdaHu0VEg9Z/mqCg/wBFa4m4XCzwhNFklBiMtmn9qZQ6EyAPCjeE1UBGaspXeiYO262lWwuyLf35KkjRXxKberuoEI9rTTGy8at3xFdLNWaljsAQxCRkG/sFIYc=
I don't mean to suggest that the issues are especially prevalent.
Out of ~40,000 domains I've found where TLSA record lookups apply,
~38000 have working denial of existence, ~1800 have actual TLSA
RRs, and only 100 or so have one or more of the above problems.
So the vast majority of domains are fine, and I am trying to reach
out to the various DNS operators who can address the problem, but
I think broader awareness of the issues to avoid and/or remediate
might be beneficial to all.
I'd like to see problems with at most a handful of domains at time,
not ~100. A year ago there were over 3000 problem domains, but
the largest providers have taken action, and now I'm faced with
herding cats in the long tail of the distribution where the number
of problem domains per provider is relatively low and working the
problem one provider at a time is no longer very effective.
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
