I would guess the upstream server used by resolved is reacting negatively to weirdness in O365 authoritative DNS.
* outlook.office365.com is indeed an alias (CNAME) for outlook.ha.office365.com.
* The domain ha.office365.com has two sets of nameservers: ns{1..4}-ms-acdc.office.com and tm{1..2}.edgedns-tm.info, which don't seem to agree with each other.
* According to the first set of nameservers, outlook.ha.office365.com is a two-layer alias for outlook.ms-acdc.office.com and then FRA-efz.ms-acdc.office.com.
* But according to the second set of nameservers, outlook.ha.office365.com is not an alias -- those servers perform some sort of CNAME flattening and directly return A/AAAA records. (Though if you ask them very nicely for CNAME records, they will actually admit that it's an alias for fra-mvp.trafficmanager.net... which is different again.)
So it is entirely possible that when resolved makes two queries, one for A records and another for AAAA, it receives conflicting information about the target simultaneously being an alias and not being an alias (due to your upstream resolver choosing different NS each time), and I wouldn't be surprised if that causes resolved to reject (or just overlook) some of the returned DNS records.
On Wed, Jan 27, 2021 at 12:11 PM Stefan Tatschner <stefan@xxxxxxxxxxxxxx> wrote:
Heya,
I was confronted with a weird problem this morning. On my location
there is only IPv4 available. My company uses the shiny new Office365
service for email. This morning I was not able to connect to my email
account. The reason was systemd-resolved returning only IPv6 addresses
for the email host:
$ resolvectl query outlook.office365.com
outlook.office365.com: 2603:1026:c0a:855::2 -- link: enp3s0
2603:1026:c0a:857::2 -- link: enp3s0
2603:1026:c0a:8b7::2 -- link: enp3s0
2603:1026:c0a:850::2 -- link: enp3s0
2603:1026:c0a:852::2 -- link: enp3s0
2603:1026:c0a:851::2 -- link: enp3s0
2603:1026:101:1::2 -- link: enp3s0
2603:1026:c0a:854::2 -- link: enp3s0
(outlook.ha.office365.com)
-- Information acquired via protocol DNS in 820us.
-- Data is authenticated: no
The `host` utility instead reports this:
$ host outlook.office365.com
outlook.office365.com is an alias for outlook.ha.office365.com.
outlook.ha.office365.com is an alias for outlook.ms-acdc.office.com.
outlook.ms-acdc.office.com is an alias for AMS-efz.ms-acdc.office.com.
AMS-efz.ms-acdc.office.com has address 40.101.12.66
AMS-efz.ms-acdc.office.com has address 52.97.250.210
AMS-efz.ms-acdc.office.com has address 40.101.121.34
AMS-efz.ms-acdc.office.com has address 52.97.155.114
AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:c03:581b::2
AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:177::2
AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:64::2
AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:206:4::2
The problem was that systemd-resolved only returned ipv6 addresses
although I have no ipv6 connectivity. Why does this happen? Is there an
artificial max. addresses limit with the sorting rule ipv6 first in
systemd-resolved?
I work-arounded it with an entry in /etc/hosts for now.
Stefan
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
