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 <ste...@rumpelsepp.org> 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel