Paul Hoffman wrote: > On Sep 11, 2020, at 7:23 PM, John Levine <jo...@taugh.com> wrote: > > > > In article <92ca6178-fe2d-407e-97fb-a9e44e264...@icann.org>, > > Paul Hoffman <paul.hoff...@icann.org> wrote: > >> On Sep 11, 2020, at 4:40 PM, Mark Andrews <ma...@isc.org> wrote: > >>> > >>> and why is it a RR type at all. > >> > >> So that the answer can be signed and thus validated. > > > > It looks to me like all of the servers for a particular zone would > > have to return the same AUTHINFO, which seems like a bad idea since > > they don't necessarily all have the same features. > > At this point, the only information we defined in the draft is for doing > client subnet. If there are server sets for a single zone where some do > client subnet, and others don't, then your concern is valid. Changing this to > an uncacheable, unverifiable EDNS option is easy.
The draft is not limited to ECS. It creates an IANA registry and allows arbitrary "local use" values to be defined. It can already be used to specify different capabilities for each nameserver for a zone, because the draft also allows: Most zone typically have multiple authoritative servers. Thus, the AUTHINFO Rdata returned from different authoritative servers for the same zone might differ. If that's not correct, and all the nameservers must return the same AUTHINFO RR, then perhaps a better name would be "ZONEINFO", all the references to "server" changed to "zone", etc. -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
