Subject: [DNSOP] Heads up: DANE TLSA lookup issues with some nameservers.

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Aug 2015 05:20:25 +0000

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.