On 9/29/20 5:21 PM, Lennart Poettering wrote: > On Di, 29.09.20 16:03, Petr Menšík (pemen...@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:
>>>
>>> 1. 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)
>
>>> 2. 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.
>
>>> 3. 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:
>
> 1. 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.
>
> 2. 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.
>
>>> 4. 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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
