In message <alpine.osx.2.11.1603011813560.36...@ary.lan>, "John R Levine" writes: > >> The NDR record is deliberately free format because changing DNS > >> servers is HARD, no really it is ridiculously hard with a ten year > >> lag. Which is of course why we won't use a new record at all: > > > > Really? We have rpm's of new versions of named supplied within > > hours of ISC's public announcements of new named releases. I'm > > sure there are similar announcements for other nameserver vendors. > > I suppose I could say web based configuration crudware a few dozen more > times, but I doubt it would sink in any more than it has before. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail.
Look at https://ednscomp.isc.org/compliance/summary.html. The EDNS COOKIE code point was only allocated in July. You have TLD operators and Alex top 1000 operators supporting it and we don't yet have the RFC out the door. Named's support in BIND 9.10.3 requires the nameserver builder to turn it on at configure time unless you are running it on Windows where it is on by default. [ I've heard one of the Linux vendors turns it on at compile time. ] It will be on by default in BIND 9.11.0. Slowness in supporting new types is not the problem of nameserver vendors. Support for routine extensions to the DNS actually gets done in a timely manner. Universal support takes a long time (which you can also see in those graphs) but you don't need universal support for new types. You need a resolver that can perform the lookup if you want to use the new type and the ability to publish the record. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
