It sounds like you are primarily interested in split-horizon DNS deployments.
That's fine, but it doesn't require the complexity of the proposal you've drawn
up here.
Instead, we can "simply" append the server's name to the response packet in
EDNS at each hop, if the stub requested it, accumulating a path in the final
response to the stub. If the stub sends queries for different names, it may
see different paths in the responses, due to split horizon, round robin, etc.
> I would like to know whether laptop to network resolver is protected
Why? What are you going to do with this information?
--Ben
________________________________
From: Petr Menšík <pemen...@redhat.com>
Sent: Monday, November 11, 2024 6:15 PM
To: Ben Schwartz <bem...@meta.com>; dnsop@ietf.org <dnsop@ietf.org>
Subject: Re: [DNSOP] Re: DNS traceroute - in-person discussion after dnsop WG
on Thursday (today)
Okay, I thought whether my idea was too dumb to even receive any reaction.
Thank you for at least some comment. But, I think each nameserver on path might
have a bit different scope. Therefore all those servers do not know the same
information
Okay, I thought whether my idea was too dumb to even receive any reaction.
Thank you for at least some comment.
But, I think each nameserver on path might have a bit different scope.
Therefore all those servers do not know the same information and are *not*
inter-changeable. EDSR is interesting piece of technology, but useful only if
you are redirected to equal server deployed on different IP or network topology.
What I had on mind were cascade of routers, virtual machines and nested
containers. They may want to know how their configured server processes the
queries received. I work mostly in enterprise networks, where internal policy
may require using just specific set of servers. For a better performance, it
may make sense to use a cascade of caching resolvers instead of TLS
point-to-point resolvers into huge cloud operated service.
Consider something I have on my (software engineer's) laptop:
+==+ authoritative servers
|
+ [ cloud based resolver, ~10k clients, RPZ filtering of malware content ]
|
+--+ [network based resolver, ~500 clients ]
|
+---+ [laptop localhost resolver, 1 client + all VMs and VPS]
|
+---+ [VM1, own localhost resolver]
+---+ [VM2, own localhost resolver, multiple VPS]
|
+---* [container1 in VM2]
+---+ [container2 in VM2, own localhost resolver]
|
+--* client APP asking for dns-traceroute
What I think is important, there are several layers of DNS caching. All of them
improves performance for their direct clients. But container localhost resolver
may know some special localhost-only names or entries. Similar with VM2, it may
know names of other containers, which are spawned on VM2. And my laptop may run
multiple virtual machines having internal only names, resolvable only on laptop
itself. network based resolver does not need to know those names, therefore
redirecting to that server leads to lost information. Similarly, I would like
my laptop to have reverse entries for all my spawned VMs, but my network
resolver does not need to know them all.
My opinion is most of DNS-OARC people work on something like cloud based
resolver. On network based resolver EDSR makes perfect sense, as does on cloud
based resolvers to choose best working instance, topologically close enough or
less loaded.
But if my clients are working with internal scopes, using private addresses and
non-public names (.internal or .home.arpa), throwing all queries over TLS to
the cloud provider directly does not seem working to me. Since most of
communication on laptop happens internally, it does not seem necessary to use
DoT servers on the laptop internally. But I would like to know whether laptop
to network resolver is protected. Yes, I trust my own virtual machines are not
lying to me and need no proof for that. Similarly network based might be
operated by own organization, where we can trust it won't lie to me.
My proposal allows me to fetch cloud provider name, even if firewall on network
boundary does not allow me to query it directly. I don't know if it is the best
practice, but is a real-world configuration of our network.
More bits below.
On 11/11/2024 15:43, Ben Schwartz wrote:
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.
I think it uses very similar semantics. Not same, but similar. They encode
information about next hop. About connection of another client to another
server, no myself. It does not seem too different, except we may want to
include unencrypted protocol usage if it is used.
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.
What I were thinking were discovering hop-by-hop path, similar to what
traceroute does on network level. Each gateway emits ICMP packet. You are not
allowed to connect to each gateway to ask directly. You use just default route
on your host and other gateways on path deliver your packets.
I think DNS can be similar. Okay, I admit client has no way to verify he is not
being lied to. But I assume since immediate hop server identity is known to
client, he may assume some trust of the service he/she is using.
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.
Except this won't work in case internal client is not allowed to make direct
connection to parent server himself. Or to other public servers on the
internet. We have such configuration in our internal offices. Internal
resolvers have RPZ policy filters on content, acting as Protective DNS service
for internal clients. Sure, IP source is not strong information. Something like
CARED draft is much better, where machine has crypto authentication of identity.
I am not proposing to encode whole policy in single response. One resolver
would know just its next-hop. Then it needs a way to identify "upstream"
resolver to its client, giving it some name. Would
_{number}._dns-forward.resolver.arpa make more sense, indicating number=2 is my
parent's parent? Returning what _1._dns-forward.resolver.arpa received to its
_dns.resolver.arpa SVCB? query?
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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-add-encrypted-dns-server-redirection-01__;!!Bt8RZUm9aw!48MFRD7YqkGl5g2xGs8EixKoPq7kQxk7j5KG9Cyy__4yK4zjIs-XRoNpl5VkhJ4yYRk2M4mkONpJYg$>),
which can provide useful SVCB records to the client of a forwarder.
--Ben Schwartz
I thank you for that draft pointer. It is interesting. But I do not think it is
useful for my use case. It requires peer-to-peer connectivity and non-changing
(name) scope. I think today's internet is full of various PROXYv2 mechanism,
delivering queries on behalf of someone else. I think also traceroute command
sends all packets to destination IP via gw, always the same. Just TTL is
changing, returning ICMP responses from different hosts. Again, traceroute
sends every packet to my default gateway. I consider default gateway as my
host's resolver and expect ability to query parent's responses.
Maybe I have just a very different idea what is meant by dns-traceroute and
what was Petr's idea. I have describe mine.
Regards,
Petr
________________________________
From: Petr Menšík <pemen...@redhat.com><mailto:pemen...@redhat.com>
Sent: Friday, November 8, 2024 3:04 AM
To: dnsop@ietf.org<mailto:dnsop@ietf.org>
<dnsop@ietf.org><mailto: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
--
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
