On Mi, 15.04.20 10:48, Florian Weimer (fweimer@xxxxxxxxxx) wrote: > > 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. Yes, resolved is a stub resolver only. And it is so regardless which interface you use to talk to it. The local listener on 127.0.0.53:53 is not a fully featured DNS server either because of that. It does stuff real DNS servers don't do (such as LLMNR, merging in /etc/hosts and stuff, such as the scope routing and so on), and we will say NOTIMPL to a vareity of requests that you can send to a real DNS server but that make no sense for a local resolving stub. Yes, this means if you have some special "dig" command line with all kinds of special options there's a good chance systemd-resolved will refuse your request, because that option is not implemented. It tries to make this discoverable as much as that is possible, by returned the most appropriate error (the error vocabulary isn't too verbose howerver) and by logging about it to syslog. Note that when you talk to resolved via the DNS protocol it will not do search list processing for you, it leaves that to the client as this was always handled, in order to not do it twice. If you talk to resolved via the bus API (i.e. over nss-resolve or so) then it will to the search list stuff server side. Beaviour in these two cases is slightly different, as mentioned elsewhere, as resolved never leaks unqualified names to upstream servers as they are. > 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. NM can tell resolved the full DNS info with per-interface info, so that resolved can merge the view of the world on each (see other mail) > > 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? Most other distributions (and even BSDs) provide a tool called "resolvconf" that various subsystems that provide DNS server info call when they learn some new DNS severs or DNS servers known go away. OpenVPN is a subsystem with DNS info, hence on most distros it will already be hooked up to "resolvconf" to provide the DNS data at the right moment. The various existing implementations of "resolvconf" usually take this info, sort it somehow and write it to /etc/resolv.conf. systemd now implements its own version of the tool which uses the information in a smarter way. Long story short: if OpenVPN is configured like it already is on other distros then we should have excellent behaviour as resolved will learn about the DNS servers correctly with the right metadata we need to do our per-interface magic. > >> 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. Do we do DANE/TLSA by default anywhere in Fedora? I mean, we realistically cannot because DNSSEC sucks in most DNS servers... But yeah, clients that want to do full DNSSEC need to talk directly to upstream DNS servers. There's a feature request to switch to a special pass-through-proxy mode in resolved as soon as some of the more special DNSSEC features are turned on in an incoming DNS client packet on the stub. it's something to think about, but having been on the other end of DNSSEC I am a bit afraid it just makes things worse: i.e. writing a DNS client that can deal with servers that expose completely different behaviour depending on some flags in the headers is extremely hard. i.e. think about this: if you send a regular DNS packet to resolved it would process it natively, answer from its cache, do its LLMNR, mDNS, /etc/hosts magic and whatever else it does. But as soon as you turn on that DNSSEC bit resolved would just proxy through without any of this, without caching, any processing, without the other information sources. A client trying to make sense of such a server will be utterly confused since without the bit set it will be exposed to resolved's behaviour and quirks and its view of the world and with the bit set it will be exposed to some upstream server's view of the world and its quirks and behaviours, which are likely very very different... Hence so far my take on it was: if you want real, fully featured DNS with all weird, strange options then talk to upstream directly, don't bother with resolved's internal stub, it's not built for that. 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
