Bind Queries log file format

[Mark Andrews]

In message <2C577494-613A-419C-82C4-402BA581C881 at 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
> lstone19 at stonejongleux.com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org