[dns-operations] Microsoft DNS DNSSEC issues

[Chad Dailey]

Thank you for your analysis, much appreciated.  I've got more homework to
do, to determine why breakage started, apparently spontaneously.  We
performed no service changes during the interval where the problem began to
manifest.

Chad

On Tue, Nov 12, 2024 at 12:21 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> 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.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20241112/a0626ec0/attachment.html>