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@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
