>As I first read about this, I thought it was going to help with root >nameserver load due to idiots, but idiots won't be implementing sane things, >so it's not about that. >It seems late in the game to add this, unless it is supported by significant >operational savings/resilience.
In my mind this is in the same category as EDE. Servers insert EDE options without knowing whether the client can do anything with the EDE or not. Inserting an EDE is relatively cheap. Likewise, inserting an extra record in an error reply is relatively cheap. >At first, I also thought that this was going to be between authoritative and >recursive resolvers, but reading fully tells me that this is between >recursive and stub/local-cache resolver? It is intended for all paths where there is a client and a server and where the server has to reply an error (other than NXDOMAIN). So stub to recursor or stub to forwarder, forwarder to recursor (or another forwarder), recursor to authoritative, etc. >about: >} "This also prevents introduction of new protocol elements where authoritativ >e >} servers intenionally return a SERVFAIL for certain queries." > >I'm intringued as to what you have in mind. This came from a DELEG discussion. A nameserver that serves a zone with a DELEG-only delegation may get a query from a client that is not DELEG-ware. It was proposed to return SERVFAIL in that case. However SERVFAIL was considered a bad idea because it will not be cached long enough leading to extra load on the server. >I also have come to understand that many things that historically were added >to additional section are now not added, and clients are expected to be very >suspicious of things there. I understand how we got to this, I'm sad because >DNSSEC ought to have made this safe, but lack of DNSSEC made this practice >into a problem. Maybe I can counter with EDNS(0) and TSIG which are part of the additional section and are widely supported. I can see your point. But the risk is mainly taking normal records from the additional section. For normal records, it is easy enough to send a separate query and get a better answer. Metadata like EDNS(0) and TSIG is both less risky and impossible to get in another way. I think the error TTL also fall into this category. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
