> On 24 Mar 2018, at 13:48, Joe Abley <jab...@hopcount.ca> wrote: > > But I think brushing the grains RRType parsing dust off the > camel is not going to do much for its posture.
+1. 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. That way, an implementer can delete the crufty code -- or not write any -- and still do the right thing (sort of) if their server sees one of these RRtypes in the wild. If there are corner cases where codes were allocated for an organisation-specific purpose* and the organisation can confirm the type codes are no longer used or needed, these could be dropped from the DNS. In some respects, old DNS type codes are like pre-RIR IPv4 allocations and we’re just stuck with those legacy choices. Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be a different story if one of those zombie RRtypes required additional processing. None spring to mind though. * I’m thinking of things like Telnic’s NINFO and RKEY*. I have no idea if those two are actually used these days and would prefer not to find out. Although they seemed a reasonable idea at the time, I’ve disowned these wayward stepchildren. And .tel FWIW. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
