* Tom Hughes: > On 15/04/2020 09:08, Florian Weimer wrote: > >> I cannot find documentation of the systemd stub resolver behavior: how >> it handles search list processing, and how it decides which upstream >> name servers to query. > > As I understand the terminology the "stub resolver" in systemd-resolved > refers to the thing that listens on 127.0.0.53 and that won't do > anything clever with single label queries because it will expect > it is answering DNS queries - that is exactly the way that Ubuntu > uses it. Well, the whole thing is a stub resolver externally, even if it doesn't speak DNS with applications. It has to perform upstream server selection and search list processing in some way. The search list processing turns into the responsibility of the local client (application) only on the DNS interface. To be clear here, glibc does not perform generic search list processing for all NSS modules, that behavior is specific to nss_dns. Any DNS lookalike that aims to replace nss_dns has to implement some search list processing from scratch. >> Most Kubernetes/OKD clusters assume that both single-label and >> multi-label query names are forwarded over DNS (contrary to ICANN >> recommendations), and that DNS servers are processed in listed order for >> all queries (no parallel queries, no randomized server selection). If >> systemd-resolved behaves differently, it can make Fedora incompatible >> with Kubernetes clusters. (This is one reason why glibc still not >> follows the ICANN recommendations.) > > When accessed via nss-resolve single label queries will be subject > to search list processing but I don't believe multi label ones will. That is reasonable (and matches ICANN recommendations), but it looks like it will break many Kubernetes deployments unfortunatelly. > It definitely doesn't use the servers on an interface in any > particular order, but I didn't think glibc did either? It has a > current server but will sometimes change it based on how well > they are responding or something. No, glibc does not do this by default. (There is a non-default “rotate” option that provides some randomness in the server selection.) Actually, Fedora's current NetworkManager/OpenVPN behavior depends on this because it lists the original system name server in /etc/resolv.conf after the ones received over OpenVPN. This means that with randomized/parallel queries, you might try to resolve internal domains over the public Internet, and get unwanted/unusable result. The second Kubernetes issue I worry about [1] is that the CoreDNS name server is installed first, and it does additional rule-based processing for in-cluster names. External DNS servers are listed later. Parallel queries and random server selection could bypass the CoreDNS service for queries that need to be handled by it. [1] I have no real Kubernetes experience, I'm relaying (perhaps imperfectly) the results of discussions I had with people who actually know something about it. >> Is this expected to work with the Red Hat VPN out of the box, or do we >> have to disable all this and use a custom configuration? Has this been >> discussed with Infosec? It looks like this will break their DNS >> sinkholing for domains such as REDHAT[.]CO (not COM). > > I think so long as the VPN interface has ~redhat.co in it's search > list then queries for that domain will be forced to the servers for > that interface if that's what is required? Does OpenVPN log the list of these domains somewhere? Or do they have to be configured manually? >> Will the built-in DNS server still support DNSSEC without validation, >> passing through the records if they are requested by the client over the >> DNS interface? The section above is not clear. > > I don't think so no. I happen to have a query to hand which fails > validation due to a bug in systemd-resolved and I get SERVFAIL when > querying 127.0.0.53 even with +cdflag on the dig command. Ugh. That will have to be fixed, otherwise it will break DANE/TLSA and other DNSSEC-mandatory functionality on upgrades: the system used to have a DNSSEC-clean path to the outside world, and after the switch to systemd-resolved, it won't. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
