[dns-operations] Microsoft DNS DNSSEC issues

[Viktor Dukhovni]

On Tue, Nov 12, 2024 at 09:41:15AM -0600, Chad Dailey wrote:

> Had an issue that started last week around 0304 CST 11/7/2024, mail
> deliverability for our Exchange service went to zero.  Looking closer it
> appears that the DNSSEC chain is failing, because an invalid RCODE is being
> returned.

NOTIMP (rather than the correct NXDOMAIN or NODATA as appropriate)
responses to queries for unexpected RRtypes by the nameservers for
mail.protection.outlook.com is a well-known, longstanding behaviour (at
least since Q1 2013, likely much earlier), but it is puzzling why your
DNS server is running into the invalid responses.

The zone in question is NOT signed, so non-EDNS fallback should happen
automatically, and your queries should just be for A/AAAA records for
which the nameservers return FORMERR as expected:

    $ dig +norecur +noall +comment +ans -t a nist-gov.mail.protection.outlook.com @ns1-proddns.glbdns.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 28750
    ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

    $ dig +noedns +norecur +noall +comment +ans -t a nist-gov.mail.protection.outlook.com @ns1-proddns.glbdns.protection.outlook.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35688
    ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    nist-gov.mail.protection.outlook.com. 10 IN A   52.101.8.50
    nist-gov.mail.protection.outlook.com. 10 IN A   52.101.9.19
    nist-gov.mail.protection.outlook.com. 10 IN A   52.101.8.52
    nist-gov.mail.protection.outlook.com. 10 IN A   52.101.11.12

Generally speaking, there is not a pervasive problem with email to
delivery to the domains they host, there is perhaps something unusual on
your end that tickles the NOTIMP replies that others manage to avoid.

> Forcing +noedns on our recursive boxes is our current
> workaround, but would prefer not to leave this in place.  Perhaps go chat
> up your favorite DNS team member?
> 
> https://dnsviz.net/d/mail.protection.outlook.com/dnssec/
> 
> Hit me up if you want the case number or other details.

This is the main reason that RFC7672 includes a work-around (or if
you like an optimisation) to skip TLSA queries for MX hosts whose
address records are unsigned.

   https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.2

   Note that DNS queries with type TLSA are mishandled by load-balancing
   nameservers that serve the MX hostnames of some large email
   providers.  The DNS zones served by these nameservers are not signed
   and contain no TLSA records.  These nameservers SHOULD provide
   "insecure" negative replies that indicate the nonexistence of the
   TLSA records, but instead they fail by not responding at all or by
   responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g.,
   SERVFAIL or NOTIMP [RFC2136].

   To avoid problems delivering mail to domains whose SMTP servers are
   served by these problematic nameservers, the SMTP client MUST perform
   any A and/or AAAA queries for the destination before attempting to
   locate the associated TLSA records.  This lookup is needed in any
   case to determine (1) whether or not the destination domain is
   reachable and (2) the DNSSEC validation status of the chain of CNAME
   queries required to reach the ultimate address records.

   If no address records are found, the destination is unreachable.  If
   address records are found but the DNSSEC validation status of the
   first query response is "insecure" (see Section 2.1.3), the SMTP
   client SHOULD NOT proceed to search for any associated TLSA records.
   ...

-- 
    Viktor.