On 9/29/20 6:18 PM, Lennart Poettering wrote: > On Di, 29.09.20 11:21, Paul Wouters (paul@xxxxxxxxx) 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. Is it relevant here who's the biggest? Ask any vendor of DNS software. All them would say, don't reinvent the wheel. It's harder than it seems. Yet you dont listen for 5 years. > > 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. May it be because they struggle to make it all working well together, where you just say this is okay? They struggle with validation and privacy, you just throw queries to whomever would respond. There were already said countless issues. You don't want to hear them. > > 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. Because they cared for DNSSEC functionality. Most of implemented in resolved is already there in dnssec-trigger and unbound. It has to be admitted, resolved has better integration with NM. > > So we actually have a chance of delivering something now, but you just > fight against it, just like 5y ago and nothing changed. They said their arguments 5 years ago and you are still refusing them. Problems which we failed to solve but you failed as well. But we just admit our implementation has limitations. > > 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. I admit, LLMNR is the only thing resolved provides. We don't have even alternative package for that in Fedora. mdns usage had to be reduced recently, because issues with printing. Local caching were done ages ago with dnsmasq, not a new thing. > >> 2) Maintain a per interface DNS cache using these libraries > > We maintain per-interface DNS caches, but with our code. And your code cannot do "dig @127.0.0.53 . rrsig" or "delv @127.0.0.53". It is not finished. > >> 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. Most of difficult things comes with strange changes during hotspot sign on. Because you don't care for DNSSEC, you don't find most of them. So any hosts used by hotspot avoids DNSSEC validation, even when it is enabled? > >> 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. Correction for that. Imagine dnssec-trigger. It discovers your broken router cannot pass DNSSEC validation, so any validation fails. Just tell user 'Hey, your box is broken. Get a replace. Continue here insecure'. And they can then ask what does it mean and how to fix it. > > 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... ;-)) I bet it uses dnsmasq inside. As its maintainer I can just say its code is ugly, but its DNSSEC support is far superrior to resolved. I am surprised, not in positive way :( > > 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... And yet it were so simple. Just use a name that you own and can prove it has no signed denial of presence. fritz.box domain is not owned by anyone. Why do they set it there? Just bad design. They just make broken designs, which you workaround. Let's get for example Turris MOX. Thing designed by DNS folks. It has nice local name out of box, turris.local. Only in local network, provided by mdns. Sure, resolved can find it! As can avahi. No problems with signatures, it just works. Because it was well designed by DNS aware people. Made in validating client in mind. Do you need it anywhere else but local network? I think these cases have simple workaround. Trust unsigned answers from local routers, when validation only proves non-existent domains. That would work well with 'router.' name Microtik uses. It would still be a hack, but better than NOIMPL on dig +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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
