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 Tue, 29 Sep 2020, Petr Menšík wrote:

is there any generic protocol exchanging what (sub)domains should be
targetted to specific DNS server?

The search domains are usually the only signal available and used for
this. RFC 7296 (IKEv2) and split-DNS (RFC 8598) defines the sent domain
name list as having a meaning of INTERNAL_DNS_DOMAIN. So it is no longer
a 'search domain' but officially a "name to resolve via the nameserver's
specified by the VPN". Whether to accept these or not is a local policy,
but usually there is a trust relationship that trusts the VPN server.

I know dnssec-trigger/unbound is able
to send queries only to specified search domains received by DHCP server.

Yes, dnssec-trigger tests the nameservers and when they pass, it calls
calls "unbound-control forward_add". This is similar to what
systemd-resolved has adopted via resolvectl.

Are you aware of any implementation independent way to store domains for
each interface?

There is none that I know of.

I think there should be just single way for connection provider to
specify, which domains should go to its DNS server. Then any split-DNS
capable software (unbound, dnsmasq, systemd-resolved) should just
implement its layer to execute such redirection in runtime. Without
special hooks in connection provider to running DNS stub.

I think using the 'search domain' from DHCP is fine. And the VPN use
cases are clear too. As long as "public network" connections never
target specific domains (eg avoid reconfiguring paypal.com)

I doubt there is already generic interface, but it seems it SHOULD be
created.

These discussions are now happening at the IETF ADD and DPRIVE working
groups. While focused on DoT and DoH, the problem is identical. We might
see a "list of domains to resolve via XXX nameserver" in the near
future. Once that happens, it should be trivial to use that with things
like resolvectl or unbound-control.

Can you point me to your support for unbound?

The support for unbound in libreswan is also really easy, as all the
lifting is done by the unbound daemon/library code. We just relay
the domain list and nameserver IPs to forward_add/delete and flush
the related zone names:

https://github.com/libreswan/libreswan/blob/main/programs/_updown.xfrm/_updown.xfrm.in

If we find a running unbound, we reconfigure it. If we don't find it, we
rewrite resolv.conf and send all queries over the VPN. As I said, I'll
work on adding systemd-resolved support here for the next version of
libreswan.

Paul
_______________________________________________
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