Stéphane,
On 4/24/25 16:28, Stephane Bortzmeyer wrote:
- I assume the transmission will contain the TTL as decremented in
the sending peer's cache.
The idea is to send the data immediately (less than one second) after
receving it.
Aha. I thought it might also be useful to get a cold cache of a new resolver
instance going -- but perhaps there are other mechanisms for that.
- As for multicast over an encrypted channel, I'm not sure how that
would work given that usually a Diffie-Hellman exchange or similar
would be included (which is p2p-specific).
We were not thinking of using an encrypted channel for multicast.
Aha, then I entirely misunderstood your Section 6.2.2, which mentions multicast
+ DoT (and not sure how to otherwise understand it):
It may be interesting to replace the unicast messages by multicast
[RFC5110] (the issues of multicast on the public Internet do no apply
here since we envision work under only one organisation). For
instance, if we use DoT for the transport of messages and if there
are 1,000 servers, having a full mesh of DoT connections may be too
much.
Peter
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
