On Di, 29.09.20 11:21, Paul Wouters (p...@nohats.ca) wrote: > No further magic should be needed. The user selects this once when > joining a new network.
This is terrible UI. It was on Windows, and it would be on Linux. You shouldn't ask questions people cannot possibly answer correctly. There's a reason why Windows remained the only big OS doing that... (And do current version still do that even, I think they hid it in some secondary menu now, and do not prompt anymore?) > > Corporate networks tend to define local zones. Home wifi routers all > > do, too. There's no clear way to know what can go directly to well-known > > good DNS servers and what needs to be resolved locally. > > Generally, resolve the names from the DHCP obtained domain name with > the DHCP obtained name servers. Yes, this is limited to one domain name, > which might not be ideal, but in general when you connect to a home or > corporate network directly (no VPN) then you should use their DNS > servers regardless. Enterprise is likely blocking port 53 (or DoT or > trying to block DoH) for security reasons. And your home network you > trust? resolved is doing just this. Note that with today's DHCP you can have many domains listed in the lease. > What is important with all of the VPN cases is that you properly flush > the cache when the VPN estalishes and terminates, so avoid having > unreachable IP's in your DNS cache. It's important not to flush other > DNS data to avoid DNS fingerprinting users across different > networks. We maintain a per-interface cache anyway. If an interface goes down its cache ceases to exist altogether. There's no flushing necessary, since it just stops existing. > In short, I don't understand the issue raised here of "How do you > determine local resources". > > For each and every domain name in the above scenario it is obvious what > nameserver to send it to. There is never a need to broadcast this over > a mix of public / private DNS servers. One example: As mentioned by someone else somewhere in this thread, apparently some private jboss domains are only resolvable via RH VPN but not listed as search domains in the server-provided VPN config. > So let me ExecSum what I wrote here. For systemd-resolved to become > a high quality DNS solution: > > 1) Remove custom DNS/DNSSEC resolving code and use a well maintained > DNS library. "Custom" is in the eye of the beholder. It appears to me you mean that in a derogatory way. I mean, given that Ubuntu has been enabling systemd-resolved since quite some time by default I have the suspicion our codebase is more often deployed IRL than the ones you listed? I mean, maybe I am wrong, but it's certainly not that this is exotic stuff as you imply. I have the suspicion this is a territorial thing, no? It feels as if you believe that DNS clients that people wo are not core members of the DNS community are inherently a bad thing, and should go away, and leave the real work to the people who actually know how things work, right? I got that kind of behaviour once before when people told us to just leave service management to the real holy men of UNIX. I mean, let's not forget: last time this came up, 5 years ago, I was so fed with dealing with this attitude of yours I just stepped away, and stopped pushing for systemd-resolved in Fedora. You and some other peeps then had your shot with dnssec-triggerd, but afaiu that didn't really go anywhere, we are still at square one, even though "millions of dollars" are behind things, as you say. So we actually have a chance of delivering something now, but you just fight against it, just like 5y ago and nothing changed. The reason systemd-resolved exists and that people have adopted it in some distros already and are now doing the same on Fedora is that is solves real problems, it improves things. It adds local caching, sane per-interface behaviour, makes VPN DNS mostly just work and so on, integrates LLMNR/mDNS and other sources of truth into one thing. If there was already something doing that we wouldn't have done resolved. But to my knowledge this doesn't exist. There are solutions to very specific problems, i.e. resolves for DNS with DNSSEC for example, but that is just one part of the problem and you cannot just ignore the rest. > 2) Maintain a per interface DNS cache using these libraries We maintain per-interface DNS caches, but with our code. > 3) Use the above sketched out process to improve your process of > deciding which interface to send the query to. This is the core > of what systemd-resolved should give to the user. It is probably > already pretty close to this when we work on integrating VPN > supprt. I understand you love the network "zone" concept. I am not a fan of the concept, but this doesn't really matter: we provide all the right IPC APIs to NM and friends to configure per-interface individually what to do. Hence, if you can convince GNOME and NM to ask people that zone question all the time (good luck!) then resolved is ready already, they just have to issue some bus calls to tell resolved what they want. > 4) Deal with hotspots separately We don't deal with captive portals at all. This is up to NM and similar solutions: they should just switch the dnssec mode in resolved as they verified captive portal auth is complete. > 5) Support user configured/prompted fallback using DoT and DoH to well > known servers in case obtained DNS servers are too broken to work > well (with DNSSEC) Again, prompting users about DoT/DoH use is — I am sorry for the strong words — simply a rubbish idea. Outside of a tiny circle of technical people noone could answer that question properly. There's no point in prompting users about things they most likely cannot answer correctly. I mean, honestly: I for one don't even know if my local wifi router can do DoT or DNSSEC these days. It's a fritzbox, one of the fancier vendors, at least in Germany, and they keep adding and updating their firmware. It didn't use to support it, but maybe it does today, there very recently was a very big update of there firmware and I know they did some DNS love on it. But I haven't rechecked if one can now talk DNSSEC or DoT with the fritzbox. And if I can't answer that question correctly without much work, then who can (who's not Paul Wouters, that is... ;-)) BTW: that specific router model exposes its web UI on a non-internet domain "fritz.box". We can't automatically determine that for that domain we can't do DNSSEC hence. DHCP won't tell us. We can't bypass the local DNS server for it, and not do DNSSEC for it, but we don't know that this is the case — noone tells us. And that means doing DNSSEC by default or DoT to some known-good server bypassing the local wifi router isn't really an option — unless you accept that you cannot talk to your local devices anymore. Which sucks hard... Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
