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.
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. Each interface can have DNS servers and search domains as well as there being global ones. There can also be search domains with a prefix of "~" which force queries for that domain to be sent to a specific interface (this is how the VPN thing works). I'm not sure what happens if there are multiple interfaces with no specific routing but I think it may try them all? 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.
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?
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. Tom -- Tom Hughes (tom@xxxxxxxxxx) http://compton.nu/ _______________________________________________ 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
