Hi Carlos, On 8 Jul 2025, at 13:57, Carlos Horowicz <[email protected]> wrote:
> That said, a simple A record lookup typically involves multiple sessions to > different authoritative servers if you follow the chain from the root — not > one long session. That depends a bit on where you are looking. Between a stub and a resolver there are often lots of messages exchanged between a small number of hosts. You could imagine a long-held session between a stub and a resolver being used to exchange many messages. If the resolution graph features forwarders between stub and resolver or between resolvers, you can also easily imagine many messages being exchanged between the same pair of hosts, in which case a long-held session might be useful. When it comes to messages exchanged between resolvers and authoritative servers, some authoritative servers might be interesting enough that a resolver often has messages to send (e.g. a COM server, or an authoritative server that serves frequently-neededresponses with low TTLs). Long-held sessions might be plausible in those scenarios. Other authoritative servers might be reached more occasionally, in which case the idea of a long-held session seems less useful. The cost of setup/teardown for the latter might well be higher than some of the other scenarios, but if it happens only occasionally perhaps that's ok. I once wrote up some ideas about long-held sessions and allowing endpoints to give hints to the other end about how long they might be kept open, which were ultimately published in RFC 7828. I remain unconvinced about how useful any of my ideas were (but surely the content added by those co-authors responsible for pushing the languishing draft over the finishing line is great). > In contrast, sessions where large responses are expected (like NSEC or NSEC3 > proofs) will almost certainly happen over TCP. Be careful about what you predict. Real life is often more weird than you expect. > Just sharing some field thoughts — thanks for your insight. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
