Bind Queries log file format

Paul Kosinski bind at iment.com
Wed Feb 8 04:58:14 UTC 2017


"I’ve been around long enough to remember when upward compatibility was
something that was expected."

Having been around since before even Unix, I must say I agree totally.

As I understand it, Linus does not take kindly to Linux Kernel changes
that break forward/upward compatibility (of the ABI). I don't think BIND
should do any less.

If a new format is needed for more extensive logging, then add a new
log option (just as new Kernel interfaces are added from time to time).


On Tue, 7 Feb 2017 22:25:36 -0600
Larry Stone <lstone19 at stonejongleux.com> wrote:

> I’ve 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.
> 
> 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). 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
> 


More information about the bind-users mailing list