RE: Bind Queries log file format

[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 bad idea.  I saw your original response that we should report it 
as a 'bug' and it was added so you could help us debugging problems.

IMHO -- it's not a bug (in the classic sense), it was an intentional 
change.  Regarding needing more info for debug, I'd encourage the approach a 
lot of tools take:  add a debug option to the config, start params, etc... to 
activate the feature.

Best regards!
John


___
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

Re: Bind Queries log file format

[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 know we love you and the work you do!  But changing that log
>   format was really a bad idea.  I saw your original response that
>   we should report it as a 'bug' and it was added so you could
>   help us debugging problems.
> 
>   IMHO -- it's not a bug (in the classic sense), it was an
>   intentional change.  Regarding needing more info for debug, I'd
>   encourage the approach a lot of tools take: add a debug option
>   to the config, start params, etc... to activate the feature.

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 generated before the crash and perhaps a
backtrace and core to deduce the steps leading to the crash. It's not
possible to re-run that scenario with debug logging.

I'll create a ticket to put the client pointer at the end if that'll
help, but note that the syntax in 9.10 was not consistent either. 9.10
would log the client pointer when the client object didn't have a valid
peer.

Mukund


signature.asc
Description: PGP signature
___
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

Re: Bind Queries log file format

[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 generated before the crash and perhaps a
> backtrace and core to deduce the steps leading to the crash. It's not
> possible to re-run that scenario with debug logging.
> 
> I'll create a ticket to put the client pointer at the end if that'll
> help, but note that the syntax in 9.10 was not consistent either. 9.10
> would log the client pointer when the client object didn't have a valid
> peer.

Adding code to allow enabling or disabling this output on the fly would
work MUCH better (as an example, see "rndc querylog"/ options "querylog
[on | off ]").

Adding a "well, we needed this one time" value to the middle of a
long-standardized log file does no customer any good and inconveniences
everyone.

You own the code and can do whatever you want to, but I'd recommend
making the default log message what it was prior to 9.10 and adding
additional fields via pre-configuration and "rndc".

AlanC



signature.asc
Description: OpenPGP digital signature
___
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

Re: Bind Queries log file format

[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 what caused it. All we have is the
> > config, log that was already generated before the crash and perhaps a
> > backtrace and core to deduce the steps leading to the crash. It's not
> > possible to re-run that scenario with debug logging.
> > 
> > I'll create a ticket to put the client pointer at the end if that'll
> > help, but note that the syntax in 9.10 was not consistent either. 9.10
> > would log the client pointer when the client object didn't have a valid
> > peer.
> 
> Adding code to allow enabling or disabling this output on the fly would
> work MUCH better (as an example, see "rndc querylog"/ options "querylog
> [on | off ]").
> 
> Adding a "well, we needed this one time" value to the middle of a
> long-standardized log file does no customer any good and inconveniences
> everyone.
> 
> You own the code and can do whatever you want to, but I'd recommend
> making the default log message what it was prior to 9.10 and adding
> additional fields via pre-configuration and "rndc".

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?

The query log is getting more fields at the end of it such as
CLIENT-SUBNET logging.

Making it a configurable option misses the reason it is the way it is -
please see the first paragraph quoted above.

This seems to be a case where having it is inconvenient, and not having
it is inconvenient.

Mukund


signature.asc
Description: PGP signature
___
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

Re: Bind Queries log file format

[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 "querylog
>> [on | off ]").
>>
>> Adding a "well, we needed this one time" value to the middle of a
>> long-standardized log file does no customer any good and inconveniences
>> everyone.
>>
>> You own the code and can do whatever you want to, but I'd recommend
>> making the default log message what it was prior to 9.10 and adding
>> additional fields via pre-configuration and "rndc".
> 
> 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?

Since we are all going to have to change our configs (and those of all
the people around the world that don't read this list), just make a
decision.

> Making it a configurable option misses the reason it is the way it is -
> please see the first paragraph quoted above.

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
to fark up your log files, but it won't screw over everyone else in the
world... once we get that data we are looking for, you can back down by
doing this other command.

> This seems to be a case where having it is inconvenient, and not having
> it is inconvenient.

I really don't care, but I hate seeing ISC make unilateral decisions
that don't really need to be made and messing up clients everywhere.

I swore after the response that I got last time I offered input on this
thread that I wouldn't be stupid enough to do it again.  I've proven
myself to be just as stupid as before.

IMNSHO: THE LOG FILE IS NOT THE PLACE FOR ONE-OFF DEBUGGING INFORMATION.
 

AlanC



signature.asc
Description: OpenPGP digital signature
___
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

Re: Bind Queries log file format

[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 end will be ok?
>
>
Appending additional info to the entry would be fine.

Mike
___
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

RE: Bind Queries log file format

[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
separate file - even if that results in duplication of a little of the
information written to more 'routine' logs, and especially if it's the
kind of information which can cheerfully be purged every hour or two.
Debug and routine log rotations (and storage) can then be different.

Of course if the log message format isn't exactly what's needed in any
particular situation, the source code is freely available.

--

73,
Ged.
___
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

Re: Reverse IPv6

[Bob Harold]

On Thu, Feb 2, 2017 at 5:44 AM, Cathy Almond  wrote:

>
>
> On 02/02/2017 02:52, Filho Arrais wrote:
> > Hi,
> >
> > Hello,
> > Excuse me the question, is there anything native to IPv6 like in IPv4
> > for PTR input?
> >
> > $GENERATE 1-254 $  PTR   100.200.236.$.examplae.com  >.
> >
> > --
>
> Bear in mind that that reverse populating your IPv6 space in entirety is
> potentially going to hurt you (the $GENERATE command actually generates
> an RR for each record which will be held in the zone in memory).  Think
> about how many records your $GENERATE is going to create.  You don't
> want to have named failing to start because it does not have enough
> memory (or the machine on which it is running does not have enough
> memory) to hold all of the PTR RRsets in the zone.
>
> Please also think about whether you need to do this or not, especially
> as the names are going to follow a generic pattern and not provide any
> useful intelligence about the host using that address.
>
> Instead, I would suggest that you just create PTR entries for the IPv6
> hosts that actually need them for some reason, or to use dynamic DNS to
> add/replace/delete them as addresses are used/discarded by dynamic clients.
>

Note that there is future work being done to solve the 'too many entries'
issue with GENERATE (does not solve the other concerns):
https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-03.txt

-- 
Bob Harold
___
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