[FR] Provide forwarders configuration similar to Discovery of Designated Resolvers
Opened this issue · 2 comments
Current behavior
Unbound can configure forwarding over both plain UDP, TCP or even also encrypted TLS. That is great. But if the client would like to know, how/whether it forwards queries somewhere, there is no simple way to query active configuration.
Especially not from unprivileged client, even on the same host.
Describe the desired feature
I think especially for localhost queries, there would be typically no danger in revealing, to which hosts it forwards and using which protocols. It should be possible to not reveal such information, if we want to keep it internal only. But some ACL should be able to configure it.
- RFC 9460 - SVCB and HTTPS Resource Records - defines SVCB record for specification of encrypted protocol.
- RFC 9462 - Discovery of Designated Resolvers - In normal way it specifies only how other client can connect to my server.
- RFC 9606 - RESINFO - Provides some information about resolver behaviour.
I think we could extend Discovery of Designated Resolvers to provide similar configuration for forwarders configured. It may even support querying for subdomains.
; this would mean forwarding to encrypted dns.google server is configured
_dns-forward.resolver.arpa. 0 IN SVCB 1 dns.google alpn="dot"
; example subdomain is forwarded to different host
example._dns-forward.resolver.arpa 0 IN SVCB 1 dns.example.net
Question is, how to use SVCB to indicate plain protocol should be used. Is there correct alpn parameter specified for that case? How plain DNS forwarding should be specified, I am not sure.
Alternative might be extending RFC 9606 RESINFO record to make that possible. But I like using SVCB a bit more.
_dns-forward prefix is just my proposal, other name is for a discussion. _dns is already taken for different use case, obviously.
Potential use-case
If I have containers running on my host, where unbound is configured, they can typically reach my DNS cache. But they cannot reach host filesystem to read it from unbound configuration. If they could query forwarders over normal DNS port, they can indicate whether forwarding from this localhost cache is still encrypted.
Such information might be needed for Zero Trust network evaluation. There, program running in container cannot know, whether his localhost leads outside that host over unencrypted connection. There is no standard way to query that. I think using SVCB not only for my own listening ports, but also for forwarding definition, might allow nice way to any application to know, how protected is DNS leading further from the service, which were read from local /etc/resolv.conf file. Because otherwise it would depend.
It should be possible to hide this information, if forwarding target is not to be revealed. In that case queries to forwarding information should not be revealed, it should respond with REFUSED. Alternatively at least NXDOMAIN.
Such information might help with troubleshooting. I think default ACL would be the same as allow recursion specification.
What would you think about this idea?
Interesting information: dnsmasq can reveal forwarders by querying CH TXT servers.bind record. Of course, it specifies only global forwarders for .. It does not support encrypted DNS, so that is kind of enough for it. I think something better could be done also by unbound.
Although unbound-control list_forwards can list forwarders nicely, it requires privileges to access the control socket. But I think just read access to forwarding information should not require any privileges from applications.