Re: Bind Queries log file format

2017-02-08 Thread Larry Stone
> On Feb 7, 2017, at 11:07 PM, Mark Andrews wrote: > > > 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:

Re: Bind Queries log file format

2017-02-07 Thread Mark Andrews
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

Re: Bind Queries log file format

2017-02-07 Thread Paul Kosinski
"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

Re: Bind Queries log file format

2017-02-07 Thread Larry Stone
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

Re: Bind Queries log file format

2017-02-07 Thread Mark Andrews
In message , Paul Roberts writes: > I have to say I agree with the approach of putting this extra info into a sep > arate file. I appreciate this could cause additional problems (disk utilisati > on, extra I/O's,

RE: Bind Queries log file format

2017-02-07 Thread Paul Roberts
. :-) Thanks, Paul -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MURTARI, JOHN Sent: 06 February 2017 17:05 To: bind-users@lists.isc.org Subject: RE: Bind Queries log file format [snip] > The additional logging info is specifically for the unus

RE: Bind Queries log file format

2017-02-06 Thread MURTARI, JOHN
> From: Warren Kumari [mailto:war...@kumari.net] > Customer: "My BIND went Boom! It's been running fine for many years, > and then for no reason at all it went Boom. Here are my log files..." > ISC: "Doh. Sorry. Unfortunately the log file doesn't have sufficient > debug info. Can you please turn

Re: Bind Queries log file format

2017-02-06 Thread Reindl Harald
Am 06.02.2017 um 14:25 schrieb Warren Kumari: I suspect perhaps some of the thread got missed (or was unclear). The reason for adding it to the main log file *by default* is because of things like: Customer: "My BIND went Boom! It's been running fine for many years, and then for no reason at

Re: Bind Queries log file format

2017-02-06 Thread Warren Kumari
asking customers to enable the additional logs after a rare event (which might not happen again for months / years) means that ISC cannot hunt down and squash the corner case bugs... W > John > > > -Original Message- > > From: Mukund Sivaraman <m...@isc.org> > T

Re: Bind Queries log file format

2017-02-06 Thread MURTARI, JOHN
ve the admin a means via rndc/config to turn it on 'debug' if needed. That also allows you to add anything else you might like in the future. John -Original Message- From: Mukund Sivaraman <m...@isc.org> To: Alan Clegg <a...@clegg.com> Cc: bind-users@lists.isc.org Subject: R

Re: Re: Bind Queries log file format

2017-02-04 Thread Timothe Litt
On 04-Feb-17 04:27, Phil Mayers wrote: > On 03/02/17 16:45, Mukund Sivaraman wrote: > >> The query log is getting more fields at the end of it such as >> CLIENT-SUBNET logging. > > Although it would be super-disruptive, has any thought been given to > moving to an entirely new log format, for

Re: Bind Queries log file format

2017-02-04 Thread Phil Mayers
On 04/02/2017 09:18, Phil Mayers wrote: On 03/02/17 16:53, Alan Clegg wrote: The "rndc" option allows those that KNOW that they may need the data begin the collection where everyone else isn't impacted. If you know that this customer is at risk, tell them "run this command, it's going FWIW,

Re: Bind Queries log file format

2017-02-04 Thread Phil Mayers
On 03/02/17 16:45, Mukund Sivaraman wrote: The query log is getting more fields at the end of it such as CLIENT-SUBNET logging. Although it would be super-disruptive, has any thought been given to moving to an entirely new log format, for example k/v or JSON? They're a lot more extendable

Re: Bind Queries log file format

2017-02-04 Thread Phil Mayers
On 03/02/17 16:53, Alan Clegg wrote: The "rndc" option allows those that KNOW that they may need the data begin the collection where everyone else isn't impacted. If you know that this customer is at risk, tell them "run this command, it's going FWIW, I would tend to agree with this

RE: Bind Queries log file format

2017-02-03 Thread G.W. Haywood
Hi there, For the avoidance of doubt, It seems to me that the stability of BIND has been improving over the last couple of years. Thank you. Keep it up. If I were hunting some rarely-seen fault condition, I think I'd write any output which is more useful for debugging than anything else to a

Re: Bind Queries log file format

2017-02-03 Thread Michael Dahlberg
On Fri, Feb 3, 2017 at 11:45 AM, Mukund Sivaraman wrote: > > > We may move it to the end of the log message (bugs ticket #44606 has > been created for looking at it). Maybe its location was poor.. please > can everyone who participated in this thread say whether having it at > the

Re: Bind Queries log file format

2017-02-03 Thread Alan Clegg
On 2/3/17 10:45 AM, Mukund Sivaraman wrote: > On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote: >> On 2/3/17 8:01 AM, Mukund Sivaraman wrote: >> Adding code to allow enabling or disabling this output on the fly would >> work MUCH better (as an example, see "rndc querylog"/ options

Re: Bind Queries log file format

2017-02-03 Thread Mukund Sivaraman
On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote: > On 2/3/17 8:01 AM, Mukund Sivaraman wrote: > > > We have the debug log level, but consider the case when an operator has > > a non-deterministic or rare crash that isn't reproducible because the > > operator has no information about

Re: Bind Queries log file format

2017-02-03 Thread Alan Clegg
On 2/3/17 8:01 AM, Mukund Sivaraman wrote: > We have the debug log level, but consider the case when an operator has > a non-deterministic or rare crash that isn't reproducible because the > operator has no information about what caused it. All we have is the > config, log that was already

Re: Bind Queries log file format

2017-02-03 Thread Mukund Sivaraman
Hi John On Fri, Feb 03, 2017 at 01:43:50PM +, MURTARI, JOHN wrote: > Folks at ISC, > > > I agree, there are an awful lot of systems and SIEM products that > > process querylogs. This one change will require a huge amount > of > > re-engineering work in customer environments. > > You

RE: Bind Queries log file format

2017-02-03 Thread MURTARI, JOHN
Folks at ISC, > I agree, there are an awful lot of systems and SIEM products that process > querylogs. This one change will require a huge amount > of re-engineering > work in customer environments. You know we love you and the work you do! But changing that log format was really a

Re: Bind Queries log file format

2017-02-02 Thread Michael Dahlberg
.On Thu, Feb 2, 2017 at 2:24 PM, Paul Roberts wrote: > I agree, there are an awful lot of systems and SIEM products that process > querylogs. This one change will require a huge amount of re-engineering > work in customer environments. > > Exactly Mukund: We use

RE: Bind Queries log file format

2017-02-02 Thread Paul Roberts
Sent: 25 January 2017 12:44 To: bind-users <bind-users@lists.isc.org> Subject: Re: Bind Queries log file format On 25 January 2017 at 10:59, Tony Finch <d...@dotat.at> wrote: > It's the address in memory of the data structure representing the client. > It is mentioned in the C

Re: Bind Queries log file format

2017-01-25 Thread Mukund Sivaraman
Hi Michael On Wed, Jan 25, 2017 at 09:11:41AM -0500, Michael Dahlberg wrote: > Mukund: > > Yea, I can respect that. However, I'm not confident that dropping it right > in the middle of the log entry was the best place for it. I have a number > of processes that monitor the query logs (it seems

Re: Bind Queries log file format

2017-01-25 Thread Michael Dahlberg
On Wed, Jan 25, 2017 at 8:51 AM, Mukund Sivaraman wrote: > > > Rememeber that not only users, but even us developers have to look at > your logs when you send them to us. > > When things are fine, the sun is shining, hay is growing.. all's fine, > and the fields in the log format

Re: Bind Queries log file format

2017-01-25 Thread Mukund Sivaraman
On Wed, Jan 25, 2017 at 08:37:45AM -0500, Alan Clegg wrote: > On 1/25/17 7:44 AM, Steven Carr wrote: > > On 25 January 2017 at 10:59, Tony Finch wrote: > >> It's the address in memory of the data structure representing the client. > >> It is mentioned in the CHANGES file (#4471)

Re: Bind Queries log file format

2017-01-25 Thread Alan Clegg
On 1/25/17 7:44 AM, Steven Carr wrote: > On 25 January 2017 at 10:59, Tony Finch wrote: >> It's the address in memory of the data structure representing the client. >> It is mentioned in the CHANGES file (#4471) and in the release notes - see >>

Re: Bind Queries log file format

2017-01-25 Thread Mukund Sivaraman
On Wed, Jan 25, 2017 at 12:44:21PM +, Steven Carr wrote: > On 25 January 2017 at 10:59, Tony Finch wrote: > > It's the address in memory of the data structure representing the client. > > It is mentioned in the CHANGES file (#4471) and in the release notes - see > >

Re: Bind Queries log file format

2017-01-25 Thread Steven Carr
On 25 January 2017 at 10:59, Tony Finch wrote: > It's the address in memory of the data structure representing the client. > It is mentioned in the CHANGES file (#4471) and in the release notes - see >

Re: Bind Queries log file format

2017-01-25 Thread Tony Finch
Michael Dahlberg wrote: > I can discern what almost all of the fields signify except for the > part "@0x7f6450002ef0". It's the address in memory of the data structure representing the client. It is mentioned in the CHANGES file (#4471) and in the release notes - see