> On Sep 19, 2020, at 5:51 AM, Ray Bellis <r...@bellis.me.uk> wrote: > > > >> On 14/09/2020 15:32, libor.peltan wrote: >> Let me leave some personal opnion/comments on this AUTHINFO idea, although I >> don't know the background here. >> There are multiple kinds of "capabilities" of an authoritative server. >> Some of them are properties of the zone, some are properties of the DNS >> server implementation, some are properties of the operational policy. For >> examples: DNS algorithm, EDNS version, network MTU, respectively. >> While it seems reasonable to disclose some properties of the zone by an >> extra zone RR (although it would probably require extra query!), the >> properties of DNS server will often vary since implementation diversity is a >> general recommendation. > > The initial drafts of what became DNS Stateful Operations (RFC 8490) included > something akin to a server capabilities exchange / negotiation. > > Personally I think EDNS is the wrong place for negotiating server properties > because unless you're using TCP there's no guarantee that the server whose > properties you've cached is going to be the one that answers the next query > you send to that address. > > The flip side is that RFC 8490 support is currently rare, and is perhaps one > of those server capabilities one wants to find out about :p > > Ray
This has been discussed on this list before but the reason we removed capabilities negotiation was that there’s no real benefit, only perceived. The capabilities flags add potential delay and another vector for additional bugs but a client still has to try the feature to see if it works as advertised. The client should just try the feature directly. This potentially reduces delay and code. Tom _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
