I was probably too hasty in saying it's the upstream resolver's fault -- it's still systemd-resolved which makes the two A and AAAA queries and aggregates their responses. The upstream just happens to choose different nameservers for both, but that's normal operation.
Either way, I'd mostly blame O365 for doing weird things, but I don't have enough DNS knowledge to say whether resolved could or should be fixed to deal with it. (Then again it wouldn't be the first time when systemd-resolved is rejecting responses that are otherwise entirely valid...) On Wed, Jan 27, 2021 at 1:27 PM Stefan Tatschner <ste...@rumpelsepp.org> wrote: > On Wed, 2021-01-27 at 13:10 +0200, Mantas Mikulėnas wrote: > > 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. > > Thanks for the analysis! I am wondering what's the issue here: > Is > > * my upstream DNS resolver broken? > * Microsoft's DNS setup broken? > * has systemd-resolved a bug? > > For the first point I will see what I can do. > > Stefan > > -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
