Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemensik@xxxxxxxxxx) 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: 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux