On Mar 24, 2018, at 13:49, Jared Mauch <ja...@puck.nether.net> wrote:
> isc/bind can and perhaps should implement logging for these > rrtypes that say they may be going away so folks can see the impact. I'm actually surprised to see that support for rarely-used RRTypes is really upsetting the camel. A combinatorial explosion of annoying workarounds for the inability of middleboxes or upstream authority servers to implement EDNS(0) properly seems like a much more plausible camel irritant to me. I'm sure there are many more like that. I can see why you could strip out lines of code by eliminating the need to parse the canonical formatting of WKS and friends, but I'm surprised that it's a notable source of complexity. It is, after all, complexity that I heard is causing the camel strain, not just lines of code. If future-BIND stops parsing an archaic RRType that I happen to use, I'm going to have to change whatever code or processes that depend on it. Maybe someone (ISC, even) is going to publish a filter that will turn all the old RRs in canonical syntax into TYPExxxx representation, and back again. New RRTypes might then need to get implemented in both BIND (because presumably they are camel-friendly) and also in the filter or filters, because perhaps we are targeting multiple nameserver implementations with our zone file. This all sounds like we're just sharing the complexity around. It doesn't sound any simpler. Maybe it's a silly example? I don't know. Could be. But I think brushing the grains RRType parsing dust off the camel is not going to do much for its posture. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
