On Sat, Mar 24, 2018 at 02:58:55PM +0000, Jim Reid wrote:
> IMO there's no need to do this in the protocol unless there is convincing
> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying
> a server could return FORMERR (or whatever) when it gets a query for one
> of these dead/zombie QTYPEs might be OK I suppose.
Absolutely no! *THAT* would add substantial run-time complexity
for no reason, achieving the opposite of any simplification that
might result from dropping support for the RRtype. If there's no
such data in your zone, return NODATA or NXDOMAIN as appropriate.
If there is such data, return that data.
This would be grossly misguided. Perhaps time to reread:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08
As for removing parsing code from tools, I sympathise with the view
that this does not remove much complexity that matters. The
complexity we really should care about is wire (protocol) complexity,
not tool complexity. One might say that *new* tools may skip
implementing obsolete RRtypes, and that users should avoid new
uses of obsolete RRtypes, but there's not IMHO much impetus
for removing support from existing tools.
That said, legacy code has some costs, and one should attempt to
eventually shed bits nobody uses. So while I agre that the priorities
are elsewhere, this too is something one might eventually pay
attention to. So I am not opposed to dropping parser support for
essentially unused types. It just needs to be down with care,
first issue deprecation warnings for a few releases, then if there
are few enough complaints, remove support.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
