[dns-operations] ns1-proddns.glbdns.o365filtering.com unreachable?

[Viktor Dukhovni]

On Wed, Jul 06, 2022 at 11:42:14AM +0200, Daniel Baumann wrote:

> ns{1,2}-proddns.glbdns.o365filtering.com resolv to the same IP, do
> not support EDNS and don't answer on TCP queries.

Well, FWIW, the same two IPs.

On Wed, Jul 06, 2022 at 11:37:38AM +0200, Stephane Bortzmeyer wrote:

> The authoritative name servers for mail.protection.outlook.com
> apparently don't reply if you use EDNS. And it seems many resolvers
> don't fallback on old-DNS (and rightly so). Seen from the RIPE Atlas
> probes, many resolvers cannot resolve names under
> mail.protection.outlook.com (here, the MX of cybercampus.fr):
> 
> ; <<>> DiG 9.16.1-Ubuntu <<>> @ns1-proddns.glbdns.o365filtering.com. NS mail.protection.outlook.com
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64702
> ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available

Their lack of support for EDNS, and more critically (for DANE) the fact
that they return NOTIMP instead of NXDOMAIN for TLSA queries, has been
known to me since May 2013, when I began work on RFC7672.

The nameservers are the reason for the recommendation to not issue TLSA
queries for the TLSA records of MX hosts (and assume they don't exist or
are also unsigned) when the address (A or AAAA, whichever exist) records
of those MX hosts are unsigned.

Without that work-around, DANE-enabled MTAs would not be able to send
email to e.g. nist.gov whose MX RRset is signed, but the corresponding
TLSA queries are difficult to distinguish from a downgrade attack if one
does not already know the zone is unsigned (hence the prior A/AAAA
status check):

    nist-gov.mail.protection.outlook.com. IN TLSA ? ; ServFail

The load balancers in question have an exceedingly "minimal" DNS
implementation.  For example, when asked for the zone's SOA, they return
it in the authority section (so both NODATA and the actual record).

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52424
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;mail.protection.outlook.com. IN SOA

    ;; AUTHORITY SECTION:
    mail.protection.outlook.com. 3600 IN SOA ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600

    ;; MSG SIZE  rcvd: 172

They've been working (in this minimal form) for 9+ years, so I do
understand (be it without much sympathy) some reluctance to fix the
various issues, b/c they've been managing to return the requisite A
records, which is however sadly all they've been expected to do.

Ideally, something better will be deployed eventually.

--
    Viktor.