Hi Petr,I am unable to meet in person about this, but I were thinking about providing some way of forwarder specification. My usage would be a common way to discover where and how are responses forwarded. The primary task for be would be discovering, how is the next hop protected, if at all.
I think DDR record _dns.server.example.com could be reused, at least partially. SVCB record seems like a good alternative, although I would need to encode in that also plaintext forwarding.
For example, I would ask localhost resolver, whatever it is: _dns-forward.resolver.arpa SVCB?Because forwarding caching server knows where does it forward, it can answer easily. And it might respond with:
_dns-forward IN SVCB 1 dns.google. alpn="dot" ipv4hint="8.8.4.4"Great, now I know next hop is encrypted by dot and leads to google. Then in theory, I might be able to ask still the localhost resolver for next hop information:
_dns-forward.dns.google SVCB?Which my localhost resolver would forward normally. Now it might indicate it uses recursive mode from there, no further forwarding.
_dns-forward.dns.google SVCB 1 .Nice thing the similar protocol may allow asking for specific domain redirection.
example.net._dns-forward.resolver.arpa SVCB?Asking for where does lead example.net. In split-horizon DNS this might help discovering differences in forwarding and presenting them, whatever resolver is configured.
I am not sure how to encode forwarding just to IP addresses. PTR-like record for in-addr.arpa reverse addresses might be a solution. Another question is how to encode plain udp or tcp protocol used, because SVCB does not specify that. Would some custom alpn be okay for that, although they are not supposed to be used in TLS session? Some new parameter instead?
I think for common configurations, it would be okay to share this information when the query source has enabled recursion. Of course similar thing should have own ACLs definition possible, making it possibly more strict. I think allowing this from localhost would be usually okay. Another question is how to encode stub zone definiton, if at all.
Do you think such idea would help you in your traceroute problem? Cheers, Petr Menšík On 07/11/2024 12:34, Petr Špaček wrote:
Hi!Have you ever debugged DNS forwarding topology with no clear idea where the packets go and why?Can be something done about it? Given enough imagination, can we invent something like DNS traceroute?If you are interested in this topic catch me after dnsop session today and we can discuss, possibly with some drinks or food...
-- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
