[dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

[Viktor Dukhovni]

On Sat, Oct 07, 2023 at 09:12:31AM -0700, jack tavares wrote:

> Interesting, it works fine with dig, but I get the same error the
> author does when I use "host"
> 
> I used to know the significant differences between "host" and "dig" but I
> have
> not used "host" in so long, I have forgotten them.

The "host" command, performs three lookups:

    - hostname IN A ?
    - hostname IN AAAA ?
    - hostname IN MX ?

In the case of "outlook-com.olc.protection.outlook.com", the "AAAA"
query elicits an uncacheable "empty" NODATA response from the
authoritative server, with just the EDNS(0) OPT record, and no SOA.

    $ dig +nocmd +norecur -t aaaa outlook-com.olc.protection.outlook.com @ns1-gtm.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38963
    ;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;outlook-com.olc.protection.outlook.com.        IN AAAA

    ;; Query time: 54 msec
    ;; SERVER: 104.47.44.8#53(ns1-gtm.glbdns.o365filtering.com.) (UDP)
    ;; WHEN: Sat Oct 07 13:18:02 EDT 2023
    ;; MSG SIZE  rcvd: 67

In contrast, the "MX" query response is more "normal".

    $ dig +nocmd +norecur -t mx outlook-com.olc.protection.outlook.com @ns1-gtm.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39567
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;outlook-com.olc.protection.outlook.com.        IN MX

    ;; AUTHORITY SECTION:
    olc.protection.outlook.com. 300 IN      SOA     bn1ffonetglb003.protection.outlook.com. hostmaster.bn1ffonetglb003.protection.outlook.com. 2023060907 10800 3600 604800 300

    ;; Query time: 58 msec
    ;; SERVER: 104.47.44.8#53(ns1-gtm.glbdns.o365filtering.com.) (UDP)
    ;; WHEN: Sat Oct 07 13:21:52 EDT 2023
    ;; MSG SIZE  rcvd: 130

When I pose the "AAAA" and "MX" questions to "unbound", the results are:

 1. $ dig +nocmd -t aaaa outlook-com.olc.protection.outlook.com @127.0.0.1
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7009
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1400
    ;; QUESTION SECTION:
    ;outlook-com.olc.protection.outlook.com.        IN AAAA

    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
    ;; WHEN: Sat Oct 07 13:24:26 EDT 2023
    ;; MSG SIZE  rcvd: 67

 2. $ dig +nocmd -t mx outlook-com.olc.protection.outlook.com @127.0.0.1
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13868
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1400
    ;; QUESTION SECTION:
    ;outlook-com.olc.protection.outlook.com.        IN MX

    ;; AUTHORITY SECTION:
    olc.protection.outlook.com. 300 IN      SOA     bn1ffonetglb003.protection.outlook.com. hostmaster.bn1ffonetglb003.protection.outlook.com. 2023060907 10800 3600 604800 300

    ;; Query time: 90 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
    ;; WHEN: Sat Oct 07 13:23:07 EDT 2023
    ;; MSG SIZE  rcvd: 130

So, it looks like "unbound" is not fond of empty NODATA replies with no
SOA.  It is I think reasonable to ask Microsoft to address the "no SOA"
NODATA response.

Meanwhile, the OP can configure "outlook.com" for IPv4-only delivery as
a work-around, if his MTA[1] is unable/unwilling to use the IPv4 addresses
when IPv6 address lookups tempfail.

-- 
    Viktor.

[1] Or consider switching to Postfix, which is able to tolerate failure
to resolve one of the candidate address families, so long as the other
resolves:

    $ posttls-finger -c -l verify -F /etc/ssl/cert.pem outlook.com
    posttls-finger: outlook-com.olc.protection.outlook.com[52.101.73.7]:25: matched peername: *.olc.protection.outlook.com
    posttls-finger: outlook-com.olc.protection.outlook.com[52.101.73.7]:25: subject_CN=mail.protection.outlook.com, issuer=DigiCert Cloud Services CA-1, cert fingerprint=E3:67:91:83:13:1F:AB:10:42:E7:93:D3:33:8A:6A:BC:87:7C:43:44:23:17:AE:5E:75:0F:7E:A3:41:66:40:65, pkey fingerprint=7B:8F:75:94:E0:08:F8:6E:32:5A:CE:17:27:09:B7:D2:23:08:20:42:1D:C1:DD:0A:B5:AF:F5:41:65:A3:ED:EB
    posttls-finger: Verified TLS connection established to outlook-com.olc.protection.outlook.com[52.101.73.7]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

[ Of course with the matched hostname derived from an unsigned MX
  lookup, the security value of the certificate match is fairly modest.
  DANE is coming to Microsoft in 2024, and at least one (canary?) domain
  is already live.  Perhaps "outlook.com" will have working inbound
  DANE some time next year. ]