Subject: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Nov 2013 21:28:13 +0000

This week I received the first report of SMTP deliveries consistently
deferred due to TLSA RRset lookup problems.  The problem site is
nist.gov which has a DNSSEC validate MX RRset:

    $ secdig() { dig +adflag +noall +comments +ans "$@" @8.8.8.8; }

    $ secdig -t mx nist.gov.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20926
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    nist.gov.	IN	MX	0 nist-gov.mail.protection.outlook.com.

with the MX host an unsigned zone:

    $ secdig -t a nist-gov.mail.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3142
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    nist-gov.mail.protection.outlook.com. 9	IN A	207.46.163.247
    nist-gov.mail.protection.outlook.com. 9	IN A	207.46.163.138
    nist-gov.mail.protection.outlook.com. 9	IN A	207.46.163.215

So far, so good, but if one tries to obtain TLSA RRs for the SMTP service
at this host:

    $ secdig -t TYPE52 _25._tcp.nist-gov.mail.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63234
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

the remote DNS server responds with SERVFAIL, not NXDOMAIN, even though:

    $ secdig -t NS _25._tcp.nist-gov.mail.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30308
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

so clearly whatever DNS load-balancing kit is responsible for
mail.protection.outlook.com (the problem happens for all names
from this domain down) has a rather incomplete DNS implementation.

What this means for DANE is that one should try to avoid sending
TLSA queries when the TLSA base domain (the desired TCP endpoint)
has been discovered to lie in an "insecure" zone.

It is extremely unlikely that when "mx.example" is insecure, somehow
through the magic of DLV "_port._tcp.mx.example" is secure.

Postfix had code to avoid such queries, but it was applied too
narrowly (only when sending to non-MX destinations), the next
snapshot will have code to suppress TLSA lookups also with insecure
MX hosts.

Barring a contrary consensus from the group I will add suitable
language to the SMTP and the OPS drafts.  (The Postfix code will
need to implement the work-around regardless, my question is whether
the work-around can be stated in the SMTP and/or OPs drafts).

Without the work-around, there will be undesirable interoperability
issues when TLSA queries are sent to DNS servers that are neither
DNSSEC not DANE TLSA aware and may misbehave when presented with
unexpected queries.

FWIW, the server in question even fails with CNAME or PTR lookups:

    $ secdig -t CNAME _25._tcp.nist-gov.mail.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38672
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Nov 2013 09:48:52 +1100

[email-masked]
	 your choice of mail handler provider is causing operational
problem.

> from this domain down) has a rather incomplete DNS implementation.

Yep, it returns NOTIMP and the developers didn't think about what
the correct response to a query type that you don't load should be.

Note a RFC 103[45] server is not permitted to serve a zone that it
can't load.  TXT and NS records are known types with no special
processing.  RFC 103[45] say what to return if the name exists and
the type doesn't and it isn't NOTIMP.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Nov 2013 23:44:53 +0000

>	 your choice of mail handler provider is causing operational

Thanks, I've already notified NIST off-list.  Any comments on the
work-around (avoiding TLSA lookup when the base-domain's A or AAAA
record is "insecure")?

> the correct response to a query type that you don't load should be.

If this is useful to anyone, the DNS servers in question are:

    mail.protection.outlook.com. IN    NS ns1-proddns.glbdns.o365filtering.com.
    mail.protection.outlook.com. IN    NS ns2-proddns.glbdns.o365filtering.com.

delegated from:

    protection.outlook.com. IN      NS ns2-gtm.glbdns.o365filtering.com.
    protection.outlook.com. IN      NS ns1-gtm.glbdns.o365filtering.com.

the latter don't appear to exhibit the problem.

> RFC 103[45] say what to return if the name exists and

In this case the name does not exist, so the nameserver should be
returning NXDOMAIN, but it snatches defeat from the jaws of victory
and indeed returns "NOTIMP":

    ; <<>> DiG 9.8.0rc1 <<>> +norecur -t TYPE52 _25._tcp.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 4960
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

which 8.8.8.8 relayed as SERVFAIL.  If there is someone from
Microsoft on this list, please forward a pointer to thread to the
appropriate interested parties.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Nov 2013 01:05:28 +0100 (CET)

> appropriate interested parties.

I haven't looked at any of the other stuff (from this discussion),
but this latter appears to be a major goof in Googles DNS server.

Forwarding NOTIMP (=permanent, do not retry) as a temporary
RC (SERVFAIL) is pretty unreasonable on my scorecard.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Nov 2013 11:20:57 +1100

> RC (SERVFAIL) is pretty unreasonable on my scorecard.

NOTIMP causes a recursive server to try other servers or if
it was a EDNS query to try a plain DNS query.
REFUSED causes a recursive server to try other servers.
SERVFAIL causes a recursive server to try other servers.

When you exhaust the list of servers you return SERVFAIL.

NOTIMP, REFUSED and SERVFAIL are not authoritative responses.

---

From: James Cloos <[email-masked]>
Date: Thu, 21 Nov 2013 12:08:38 -0500

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> with the MX host an unsigned zone:

Given insecure a/aaaa results, it is reasonable to presume that tlsa
resaults also will be insecure.

Avoiding the tlsa lookup has the downside of serializing the requests,
but that appears to be necessary in the face of b0rked auth servers.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Nov 2013 17:29:34 +0000

> resaults also will be insecure.

Thanks, this is on the list for inclusion in the OPS and SMTP drafts.

> but that appears to be necessary in the face of b0rked auth servers.

Yes, though for Postfix the serialization is unavoidable, TLS policy
is loaded one MX destination at a time (in preparation for delivery
to that destination), after the network address is already in hand.

[ The network address is needed early for loop elimination.  Postfix
determines whether it is an MX host for the destination by comparing
network addresses, not hostnames.  Therefore the network addresses
of all equal-preference hosts need to be available, before delivery
to any host at that preference.  Hence the $proxy_interfaces
parameter for MX hosts behind a NAT. ]

Also Postfix + DANE requires a validating resolver on the loopback
interface, so latency is a bit less of a concern, at least for
high-volume destinations where the local cache amortises lookup
latency.

-- 
	Viktor.