On Mi, 15.04.20 09:29, Fedora Development ML (devel@xxxxxxxxxxxxxxxxxxxxxxx) wrote: > > 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. correct. > 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). Small addition: the "~" thing will declare a domain as suitable for routing only. i.e. classic search domains are used both for suffixing and for routing, but those prefixed with "~" are used for routing only and not for suffixing. Classic DNS doesn't know the routing concept, it thus only uses search domains for suffixing. We are hence using this information provided to us for more than it was originally intended, but this should be an OK thing to do. > I'm not sure what happens if there are multiple interfaces with > no specific routing but I think it may try them all? Exactly. If our routing info doesn't help us our logic is to route queries to all scopes in parallel. 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
