On Mi, 15.04.20 10:08, Florian Weimer (fweimer@xxxxxxxxxx) wrote: > > systemd-resolved has been enabled by default in Ubuntu since Ubuntu > > 16.10, but please note we are doing this differently than Ubuntu has. > > Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional > > nss-dns provided by glibc upstream, so glibc on Ubuntu continues to > > read /etc/resolv.conf, as is traditional. This extra step is not > > useful and not recommended by upstream. We want to follow upstream > > recommendations in using nss-resolve instead. > > 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. systemd-resolved generally manages DNS servers and search lists per interface, if possible. Basically, each interface that is up and has DNS info associated with it gets a "scope" associated with it. If there's global DNS configuration (i.e. read from /etc/resolv.conf if that's a regular file), then that's considered an additional "scope". Whenever looking up a hostname systemd-resolved will match the name against all current scopes and issue queries on all matching ones in parallel. Scopes are considered "matching" if the hostname being looked up has a suffix of one of the search domains configured for the scope. If no scopes match given the search domains, the query is sent to all scopes in parallel. This has some nice effects. Let's say you have one wifi interface and one vpn interface. The latter has "redhat.com" as search domain, the former has "fritz.box" as search domain configured. Now you try to look up a name "quux.redhat.com". Because the vpn has "redhat.com" as search domain the query will only be sent onto the vpn. If you look up "wuff.fritz.box" otoh it will be sent only to the local wifi. if you look up "systemd.io" otoh (i.e a domain for which no search domain is configured on any local interface), the query is sent to both scopes in parallel. If a query is sent to multiple scopes in parallel then the the first positive answer wins. If there are no positive answers than the last negative one wins. This if you are connected to two different networks with private DNS zones, the view is merged. Search domains are also used to suffix unqualified names. Note that resolved is a lot more strict than traditional DNS clients: single-label names are considered unqualified, and multi-label names are considered qualified. Unqualified names are never queried as they are on public DNS, but require a search domain of some kind to be configured with which they can be suffixed. Qualified names are never subject to search domain suffixing however. Search domains/query routing are a bit more complex than what i describe above. See the man page for further details: https://www.freedesktop.org/software/systemd/man/systemd-resolved.html#Protocols%20and%20Routing resolved will start using the first DNS server configured for a scope, and stick to it for subsequent lookups. When an error is seen from it, it will switch to the next DNS server and then stick to that for future lookups. i.e. it basically "caches" whether the first lookup worked or not to speed up subsequent lookups. This means if the first listed DNS server is borked and doesn't respond you'll pay for it during the first lookup only, but all subsequent ones would use the working one immediately. This is of course quite different from nss-dns where on every single lookup things begin with the first DNS server configured. resolved's behaviour on this hence assumes that all DNS servers configured on a scope are equivalent in the zones they provide. Or to turn this around, if you have multiple DNS servers offering different views of the world, then configure each set of them on a separate interface, so that they become different scopes and thus can be queried in parallel. > 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). resolved never sends single-label names to public DNS, under the assumption they have local meaning only, and should not leak onto the internet. They will end up on the Internet only if a search domain is defined that can be used to qualify them. systemd-resolved starts with the first listed DNS server initially, but as mentioned if it fails it will switch to the next DNS server and then stay with it for subsequent lookups, unlike nss-dns which starts from the beginning on every single query. If passing single-label un-suffixed to the DNS servers is mandatory for OKD/kubernetes, and if starting with the first DNS server on every single lookup is too, then such images should probably override /etc/resolv.conf with their own. I am pretty sure that both these behaviours of kubernetes/OKD only make sense in a very specific environment, and are not approproate for general purpose systems. > systemd-resolved behaves differently, it can make Fedora incompatible > with Kubernetes clusters. (This is one reason why glibc still not > follows the ICANN recommendations.) > > With the Ubuntu approach, search list processing still resides within > glibc, so their Kubernetes experience would not necessarily match > ours. Hmm, containers usually don#t boot up systemd inside, and thus usually don't get resolved inside them anyway either. Hence my guess would be that ubuntu just copies in upstream DNS info directly to /etc/resolv.conf when starting the container, at which point what resolved does doesn't matter at all anymore. > Will Fedora treat such cross-VPN leaks as security bugs going and > forward and fix them? (I suspect it would require constant work, and > lots of 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). If RH VPN configures "redhat.com" as search domain for their VPN then this means all redhat.com traffic is automatically pulled over to the VPN and will not be routed elsewhere anymore. > 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. depends on the record type. A number of DNSSEC RR types are magic, and we'll refuse sending those to DNS servers that we don't think speak DNSSEC. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
