> 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: rock.dv.isc.org IN A -SE(0)D
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
"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’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 wi
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, log rolling etc.) but I would prefer to keep the query log f
> ormat as stable as pos
just keep the log format the same. :-)
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 loggin
> 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 o
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 a
- 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
> To: Alan Cleg
d say give 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
To: Alan Clegg
Cc: bind-users@lists.isc.org
Subject: Re: Bind Qu
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 exam
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,
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 go
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 approach;
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
s
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 end will be ok?
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 "query
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 wha
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 gener
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 kn
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 ba
.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 Splunk to analyze the querylogs
Sent: 25 January 2017 12:44
To: bind-users
Subject: Re: Bind Queries log file format
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 -
&g
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
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 that a user want
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) and in the release
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
>> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.gi
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
> > https://source.isc.org/cgi-
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
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c4b7db49326be650fa95a7ede6e
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
https://source.isc.org/cgi-b
30 matches
Mail list logo
