I don't think we should reuse SVCB records in this way. The records here do not have SVCB semantics, so I think it would be very confusing.
In general, I have difficulty understanding the problem that is being solved here. DNS forwarders can have arbitrarily complicated, customized policies that we cannot hope to standardize. It's also not clear how this information helps the client, especially since it is unverifiable. The discussion of "DNS Traceroute" on a per-message basis makes a lot more sense to me, as it avoids the need to encode the entire forwarding policy in advance. Instead of this direction, I would encourage you to look at EDSR (https://datatracker.ietf.org/doc/html/draft-ietf-add-encrypted-dns-server-redirection-01), which can provide useful SVCB records to the client of a forwarder. --Ben Schwartz ________________________________ From: Petr Menšík <pemen...@redhat.com> Sent: Friday, November 8, 2024 3:04 AM To: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] Re: DNS traceroute - in-person discussion after dnsop WG on Thursday (today) 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
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
