Mark Andrews wrote: > There are three things that made it hard to deploy new features. > > 1) Firewall vendor shipping firewalls with ridiculously strict rules > with zero evidence that they are needed. > > 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors. > > 3) Unknown EDNS option behaviour was not well defined by RFC 2671, > this is addressed in RFC 6891. > > 1 and 2 made it impossible to do a clean update from RFC 2671 to > RFC 6891 which tightened the unknown EDNS option behaviour. Proper > implementation of RFC 2671 would have allowed the EDNS version 1 > to be used to signal that RFC 6891 unknown option behaviour is > required.
I'm more that willing to strip out any opinionated text in the draft about what makes it hard to deploy new DNS features. I agree that there is a lot of bad code out there, but my primary use case is for greenfield deployments where both client and server side have new code, and there is a need to detect the other side's capabilities. If you have old or bad code running in the client, server, or middlebox, you just don't get to use the new features. > I don't see how adding a capabilities option will help here when > the primary problem is bad code. There are cases where all you need is a feature flag, and in some cases, the ability to remember an advertised feature for subsequent queries. Currently there are 16 reserved bits between the DNS and EDNS headers that require standards action to use. The small number of bits available and the difficulty required to obtain one (the last allocation was over 10 years ago) means that an EDNS0 option is a more likely path for a feature flag, but that path wastes a minimum of 5 octets. There's a limited amount of space available in a UDP DNS query packet, maybe around ~200 octets for a query with a maximum length QNAME and a plausible set of EDNS0 options. The "DNS Features" capability in my proposal provides space for 256 feature bits at a cost of up to 32 octets. If we make that space a FCFS registry (and provide a handful of "Reserved for Local/Experimental Use" bits) it becomes easier to experiment with new features (using a new bit in an existing EDNS0 option is easier than implementing an entirely new EDNS0 option). -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
