On 9/29/20 5:21 PM, Lennart Poettering wrote:
On Di, 29.09.20 16:03, Petr Menšík (pemensik@redhat.com) wrote:
For example, if I have my laptop in my home wifi, connected to RH VPN, then there are some names resolvable only via the local DNS. Specifically: my router's, my printer's and my NAS' address. And there are other names only resolvable via RH VPN. systemd-resolved for the first time gives me a chance for this to just work: it will send requests to both the RH DNS servers and the local ones, and uses the first successful reply, or the last failed reply. And that's quite frankly awesome, because that *never* worked before.
Would you please try dnssec-trigger? It does exactly this thing. Unlike resolved, it can do that also with DNSSEC support on client side. But it is not system default.
Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is opt-in though.
Are you sure? Can it?
# systemctl restart systemd-resolved $ resolvectl | grep DNSSEC DNSSEC setting: allow-downgrade DNSSEC supported: yes
# delv @127.0.0.53 ;; validating ./NS: got insecure response; parent indicates it should be secure ;; insecurity proof failed resolving './NS/IN': 127.0.0.53#53 ;; resolution failed: insecurity proof failed
# delv ; fully validated . 503266 IN NS a.root-servers.net. . 503266 IN NS b.root-servers.net. . 503266 IN NS c.root-servers.net. . 503266 IN NS d.root-servers.net. . 503266 IN NS e.root-servers.net. . 503266 IN NS f.root-servers.net. . 503266 IN NS g.root-servers.net. . 503266 IN NS h.root-servers.net. . 503266 IN NS i.root-servers.net. . 503266 IN NS j.root-servers.net. . 503266 IN NS k.root-servers.net. . 503266 IN NS l.root-servers.net. . 503266 IN NS m.root-servers.net. . 503266 IN RRSIG NS 8 0 518400 20201012050000 20200929040000 46594 . EUNUgwVVvcgdX6JRCPfmhFPuIJW8DZf7ww1hQAgek0GPDT7kc75fER5Z NpASxPhrTQKentVt/C5ptwa0Z58i8O7XyN6Pu5ZIZrOpG5zV6y0FqLnI B7L01ugkmTdZIxfqTxbyiTh8hTWspskbAYQrnrSPiotX0+POYlw7ZIwX R6V7Y2mF48wFclaejrPRQy/ee03QKYyT9nYPahe7i0qnbmvk1JAfDiCw dR6Aa2hm/RSuW+7nJRqCbeDZZ4mU1lAZDiyUQ1ezAl/HcCCcpBud8iae DBYFXDX86EP0hXQexpzN5MLUQZuTCIq5Ihz9Vqk0orXmeaZ/k56t/2td /ak8sw==
# rpm -q systemd systemd-246.6-2.fc34.x86_64
How can I tell it works? Is servfail on dnssec-failed.org enough?
So no, that is not as fresh as you say. Just have to specify subdomains, that should be sent to specific server. Not just trying anyone that works. Mind my privacy, not everyone has to know what am I resolving.
I move my laptop around, I want something that just works. And I am pretty sure that's the same for Fedora: a DNSSEC implementation that is opt-out but requires manual config is a no-go.
So sending the requests to all available DNS servers in absence of better routing info is a great enabler: it makes DNS "just work" for many cases, including my own, and I doubt it's a particularly exotic one.
It takes privacy from you and make it much worse. Just because it does 'just work'. Wouldn't it make sense to let corporate admins specify, what should be routed there? Do you know enterprise VPN, which is configured by BFU?
It provides the same privacy guarantees as your solution — as long as you tell it the routing domains. The only difference: if you don't tell it anything resolved's behaviour "just works", while your solution means things do not just work.
You know that meme, "It's not DNS. There's no way it's DNS. It was DNS"? I am pretty sure we shouldn't adopt defaults that break for the common cases out-of-the-box. Hence, in absence of more explicit routing info I am very sure "just works" is better than "just fails".
Yes, the logic does potentially allow more than you#d want onto some interfaces, but I don't think a (fake?) sense of "privacy" is a good excuse for "let's ship something that cannot work by default".
Yes, I too would prefer if my regular, non-RH DNS traffic never goes to RH servers while I am in the VPN, and I can easily configure things that way. But if I am pretty sure the majority of people probably put more emphasis "please please work" than on "i'd rather have not working DNS than have DNS queries end up on RH's DNS servers".
Key, take-away here:
- Ideally we'd just route company DNS traffic to VPN, and everything else to local LAN DNS. But that requires explicit routing info to be configured, we cannot auto-detect this info (beyond some minor inference from the search domains)
Let company configure it via VPN, allow local override for power users.
VPNs generally do not propagate domain routing info. They do provide search domain info, which — as mentioned — we infer routing info from. And yes, we of course allow local override.
So: check and check? (to the level this is possible)
- In some cases hence routing all DNS traffic via VPN and nothing via local might be a workable option. In others this would be wrong.
Can you please be more specific? Example we can argue about? _gateway is just bare name, it would make sense to send it to LAN. Anything else?
This is what the person I replied to asked for: if VPN is up send all DNS traffic to VPN, none to local DNS server.
- In others routing all DNS traffic via local DNS and nothing via VPN might be workable option. In others this would be wrong.
Never heard about this. Can you provide an example, where is this configuration desired? Is there public product or company, that configures it service like this? Do they offer DNS server in DHCP/autoconfiguration, when they do not want it to be used?
You appear to one of those who wants that, i.e. no have DNS traffic end up at RH that shouldn't go there if you are in the VPN.
What this boils down to: there are primarily two usecases for VPN I see:
employee talks to company VPN to access very specific servers. For cases like this ideally only company DNS traffic goes to VPN and nothing else. i.e. porn domain lookups only go to local LAN DNS.
user uses public VPN services such as mozilla VPN or Private Internet Access or a similar service to obstruct the view on what they are doing to the local network. In this case all DNS traffic should go to VPN and nothing to local LAN DNS.
Both usecases are equally valid and probably equally popular. We can't guess what is right.
In the first case the local LAN is more "trusted" if you so will than the company VPN: pornsite DNS traffic should go to LAN, but not to VPN. In the latter case the local LAN is less trusted than then used VPN: pornsite DNS traffic should go to VPN, but never to LAN.
- In all cases where we can't do #1 because we lack the info, and don't know whether to do #2 or #3 because it depends on the type of VPN use, then sending to everything in parallel and taking the first positive reply and the last negative one is the best chance to make things "just work".
Then work on getting the info. If you don't know which variant, choose the same as without resolved. That usually would be #2, right? If that VPN specified server and it has higher priority, route there. Use any place default route is sent to.
Well, except that the info is not provided via openvpn and similar solutions. I can't make it up from thin air.
But I really want to access servers inside the RH VPN and my local router/printer/NAS at the same time, so I am totally happy that with resolved this now *just works* even if RH's VPN doesn't tell us anything about routing domains.
Anyway, I think I am repeating myself here.
Sure, you repeat yourself. But turn the deaf ear to arguments of others. Please use smart defaults, only when they don't endanger user's privacy nor security.
I don't think what you are saying is congruent. On one hand you want that VPNs do not get all DNS traffic apparently, on the other you say it should have preference over the LAN DNS in all cases if it is configured? So what is it now?
Anyway, I still believe that making things just work is the best option, and buying vague "privacy" by "it's ok if it doesn't work" is a shitty deal.
Lennart
-- Lennart Poettering, Berlin