In message <2c577494-613a-419c-82c4-402ba581c...@stonejongleux.com>, Larry Stone writes: > Ive been around long enough to remember when upward compatability was > something that was expected. A program built to work with the current > version of data (e.g. data records, log records, whatever) or even a > shared library was expected to be able to continue to work with all > future versions without the need for changes or rebuilding/recompiling. > For data, that meant new fields went on the end of the record so that > anything expecting the old format still found everything where it always > was and the new stuff was at the end of the record where the old programs > never even looked. But sadly, this appears to be a lost art these days.
BIND 9.12.0 will work with valid zone files from BIND 4.8. Named has got better with detecting errors in those zone files so a modern version will reject some zone files that were incorrectly accepted by BIND 4.8. > Where I work, we have a data set that has 20 years of data in it. Over > the years, the record length was extended but once a field was placed at > a given point in the record, it never, ever moved so that programs > written years ago that had no need for the new fields still ran just > fine. And with hundreds if not thousands of programs around the company > that read this data set, insuring that format changes did not break > things was a very high priority. Occasionally, fields went away in which > case that spot in the record was just left blank for all new records. > > For the BIND log records described below, what I describe appears to be > what was done through 9.10.0. But then at 9.11.0, we have a field in the > middle of the record being changed (EDNS changed to EDNS+version). No, we have a field that has more information in it. Same field E -> E(version) 08-Feb-2017 15:15:44.532 client @0x7fc1c803c600 127.0.0.1#57982/key external (rock.dv.isc.org): view external: query: rock.dv.isc.org IN A -SE(0)DV (127.0.0.1) Or with ECS 08-Feb-2017 15:56:27.109 client @0x7fc1c503e800 127.0.0.1#63454 (.): view external: query: . IN SOA -E(0)DV (127.0.0.1) [ECS 127.0.0.0/8/0] Or from a stub resolver. 08-Feb-2017 16:02:22.971 client @0x7fc1c490dc00 127.0.0.1#61028 (sprocket.isc.org): view secure: query: sprocket.isc.org IN A + (127.0.0.1) Mark > What, > IMHO, should have been done here was to put the version on the end > (either going with a split filed - EDNS in one place and the version in > another or by duplicating EDNS by having it without version where it was > and then again with version on the end of the record) so that old > programs parsing the log file still worked. So instead of: > > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, > local address > > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, > DO, CD, cookies, local address > > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, > DO, CD, cookies, local address, ecs > > > it should have been > > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, > local address > > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, > cookies, local address, EDNSversion > > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, > cookies, local address, EDNSversion, ecs > > -- > Larry Stone > lston...@stonejongleux.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
