Re: shutting up logs
Hi there, On Fri, 15 May 2015, Reindl Harald wrote: Am 15.05.2015 um 02:01 schrieb Nick Edwards: > skipping nameserver 'ns5.concord.org' because it is a CNAME, while > resolving '210.128-25.119.138.63.in-addr.arpa/PTR' > > I have logs grow by about 30 megs a day with pretty much only this in > it (of course not always same remote server), how do I shut this up ? > ... you can't ... You can. If you use syslog-ng you can do anything you like, for example you can filter messages using regular expressions. If there wasn't a syslog-ng, I'd have to write one. -- 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: shutting up logs
You can silence the messages by sending category cname to null, but
have you tried contact the zone administrator postmas...@concord.org
to get the delegation fixed. One of the points of logging the
configuration error is to make it visible so it can be fixed. The
second reason is to have evidence of why a lookup is failing.
128-25.119.138.63.in-addr.arpa. 3600 IN NS ns5.concord.org.
128-25.119.138.63.in-addr.arpa. 3600 IN NS ns6.concord.org.
;; Received 106 bytes from 66.155.216.121#53(ns1.paetec.net) in 409 ms
128-25.119.138.63.in-addr.arpa. 10800 IN NS cable.concord.org.
128-25.119.138.63.in-addr.arpa. 10800 IN NS barney.concord.org.
128-25.119.138.63.in-addr.arpa. 10800 IN NS dns1-bos.paetec.net.
;; Received 144 bytes from 63.138.119.200#53(ns6.concord.org) in 407 ms
Alternatively complain the the parent zone (d...@paetec.net) about
the delegation being broken and request that it be fixed / removed
as it is causing operational issues as per RFC 1034.
Mark
In message
, Nick
Edwards writes:
> skipping nameserver 'ns5.concord.org' because it is a CNAME, while
> resolving '210.128-25.119.138.63.in-addr.arpa/PTR'
>
> I have logs grow by about 30 megs a day with pretty much only this in
> it (of course not always same remote server), how do I shut this up ?
>
> My logging statments are
>
> logging {
> category lame-servers { null; };
> category edns-disabled { null; };
> category client { null; };
> category dnssec { null; };
> // channel log_queries { file "/tmp/debug_query.log";
> print-category yes; };
> // category queries { log_queries; };
> };
>
> TIA
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: shutting up logs
Another option might be changing 'file' to 'syslog' then using stuff like
":msg, contains, 'skipping nameserver' stop" (or whatever pattern you want
to match) in your rsyslog configuration.
http://www.rsyslog.com/doc/rsyslog_conf_filter.html
-Original Message-
From: Reindl Harald
Organization: the lounge interactive design
Date: Thursday, May 14, 2015 at 8:44 PM
To: "bind-users@lists.isc.org"
Subject: Re: shutting up logs
>
>
>Am 15.05.2015 um 02:01 schrieb Nick Edwards:
>> skipping nameserver 'ns5.concord.org' because it is a CNAME, while
>> resolving '210.128-25.119.138.63.in-addr.arpa/PTR'
>>
>> I have logs grow by about 30 megs a day with pretty much only this in
>> it (of course not always same remote server), how do I shut this up ?
>>
>> My logging statments are
>>
>> logging {
>> category lame-servers { null; };
>> category edns-disabled { null; };
>> category client { null; };
>> category dnssec { null; };
>> // channel log_queries { file "/tmp/debug_query.log";
>> print-category yes; };
>> // category queries { log_queries; };
>> };
>
>you can't shut up specific messages
>but you can limit the log file sizes
>
>logging
>{
> channel default_log
> {
> file "data/named.log" versions 0 size 1m;
> severity dynamic;
> print-time yes;
> print-category yes;
> };
> channel transfer_log
> {
> file "data/transfer.log" versions 0 size 1m;
> severity dynamic;
> print-time yes;
> print-category yes;
> };
> channel rate_limit_log
> {
> file "data/rate_limit.log" versions 0 size 1m;
> severity dynamic;
> print-time yes;
> print-category yes;
> };
> channel lame_servers_log
> {
> file "data/lame_servers.log" versions 0 size 1m;
> severity dynamic;
> print-time yes;
> print-category yes;
> };
> channel query_errors_log
> {
> file "data/query_errors.log" versions 0 size 1m;
> severity dynamic;
> print-time yes;
> print-category yes;
> };
>
> category default {default_log;};
> category resolver {default_log;};
> category security {default_log;};
> category xfer-in {transfer_log;};
> category xfer-out {transfer_log;};
> category config {default_log;};
> category queries {default_log;};
> category notify {default_log;};
> category database {default_log;};
> category rate-limit {rate_limit_log;};
> category lame-servers {lame_servers_log;};
> category query-errors {query_errors_log;};
>};
>
___
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: shutting up logs
Am 15.05.2015 um 02:01 schrieb Nick Edwards:
skipping nameserver 'ns5.concord.org' because it is a CNAME, while
resolving '210.128-25.119.138.63.in-addr.arpa/PTR'
I have logs grow by about 30 megs a day with pretty much only this in
it (of course not always same remote server), how do I shut this up ?
My logging statments are
logging {
category lame-servers { null; };
category edns-disabled { null; };
category client { null; };
category dnssec { null; };
// channel log_queries { file "/tmp/debug_query.log";
print-category yes; };
// category queries { log_queries; };
};
you can't shut up specific messages
but you can limit the log file sizes
logging
{
channel default_log
{
file "data/named.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel transfer_log
{
file "data/transfer.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel rate_limit_log
{
file "data/rate_limit.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel lame_servers_log
{
file "data/lame_servers.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
channel query_errors_log
{
file "data/query_errors.log" versions 0 size 1m;
severity dynamic;
print-time yes;
print-category yes;
};
category default {default_log;};
category resolver {default_log;};
category security {default_log;};
category xfer-in {transfer_log;};
category xfer-out {transfer_log;};
category config {default_log;};
category queries {default_log;};
category notify {default_log;};
category database {default_log;};
category rate-limit {rate_limit_log;};
category lame-servers {lame_servers_log;};
category query-errors {query_errors_log;};
};
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
shutting up logs
skipping nameserver 'ns5.concord.org' because it is a CNAME, while
resolving '210.128-25.119.138.63.in-addr.arpa/PTR'
I have logs grow by about 30 megs a day with pretty much only this in
it (of course not always same remote server), how do I shut this up ?
My logging statments are
logging {
category lame-servers { null; };
category edns-disabled { null; };
category client { null; };
category dnssec { null; };
// channel log_queries { file "/tmp/debug_query.log";
print-category yes; };
// category queries { log_queries; };
};
TIA
___
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: Future of BIND's built-in empty zone list
Add before we get the ticket to add it. 4117. [protocol] Add EMPTY.AS112.ARPA as per RFC 7534. Mark In message , Rob Foehl writes: > On Thu, 14 May 2015, Chris Thompson wrote: > > > Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the future > > of the seemingly ever-expanding built-in empty zone list in BIND? > > > > One possibility that seems plausible to me is to add EMPTY.AS112.ARPA > > to the list now, and remove existing entries if and when the corresponding > > names in the public DNS acquire DNAMEs pointing to that (hopefully ones > > with large TTLs). > > Adding empty.as112.arpa to the list seems like a good idea, but removing > the existing empty zones does not -- they also prevent leaking internal > queries, which is both more noise for the root/IANA/AS112 infrastructure > to sink and a potential privacy concern. > > There's also the minor benefit of fast responses from local resolvers, > which still matters for determinism in the initial query. From where I > sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or > v6), and the existing AS112 nodes aren't much better. > > What would be gained by shrinking the number of empty zones? The only > thing that comes to mind is that it'd make life marginally easier for > those who run cache hierarchies and override some of those zones at the > top level, but there's already an option for that and I'm definitely > grasping at straws here... > > -Rob > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Future of BIND's built-in empty zone list
On Thu, 14 May 2015, Chris Thompson wrote: Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the future of the seemingly ever-expanding built-in empty zone list in BIND? One possibility that seems plausible to me is to add EMPTY.AS112.ARPA to the list now, and remove existing entries if and when the corresponding names in the public DNS acquire DNAMEs pointing to that (hopefully ones with large TTLs). Adding empty.as112.arpa to the list seems like a good idea, but removing the existing empty zones does not -- they also prevent leaking internal queries, which is both more noise for the root/IANA/AS112 infrastructure to sink and a potential privacy concern. There's also the minor benefit of fast responses from local resolvers, which still matters for determinism in the initial query. From where I sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or v6), and the existing AS112 nodes aren't much better. What would be gained by shrinking the number of empty zones? The only thing that comes to mind is that it'd make life marginally easier for those who run cache hierarchies and override some of those zones at the top level, but there's already an option for that and I'm definitely grasping at straws here... -Rob ___ 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: EDNS and fallback
On 14/05/15 22:02, Bischof, Ralph F. (MSFC-IS40)[NICS] wrote: Hi Ralf, > symptoms I am seeing is that a dig command sends out several queries > with EDNS and bufsize of 4096. The server on the other side of this I think this is the pertinent point. You're testing with dig, but dig doesn't fallback to smaller buffer sizes. That only happens within the named process. You should run named with debugging turned on, and then send it queries to resolve, and observe buffer size fallback. Regards, Anand ___ 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
EDNS and fallback
Hello, I am trying to understand EDNS queries and the fallback capabilities. BIND 9.9.6-P1. I have a particular scenario where two sites are connected via firewall links and UDP fragmentation is not allowed. The symptoms I am seeing is that a dig command sends out several queries with EDNS and bufsize of 4096. The server on the other side of this setup answers back with an answer sized at 3410, yet no packets reach back to the dig query. According to the Knowledgebase article linked below, I expected to see the client fallback to EDNS with a bufsize of 512 when it did not receive a reply. Am I wrong? I have also listed the part that concerns me. https://kb.isc.org/article/AA-01219/30/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html "For currently (and recently) supported versions of BIND up to and including BIND 9.9, the fallback algorithm for a 'new' authoritative server operates as follows: Query with EDNS, advertising size 4096, DO (DNSSEC OK) bit set If no response, retry with EDNS, size 512, DO bit set" Perhaps it has something to do with the meaning of "'new'"? Thank you, Ralph F. Bischof, Jr. The opinions expressed within this communication are not necessarily those of NASA. ___ 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: Future of BIND's built-in empty zone list
Am 14.05.2015 um 18:29 schrieb Chris Thompson: Now that RFCs 7434 & 7435 have been published, how do ISC see the future of the seemingly ever-expanding built-in empty zone list in BIND? One possibility that seems plausible to me is to add EMPTY.AS112.ARPA to the list now, and remove existing entries if and when the corresponding names in the public DNS acquire DNAMEs pointing to that (hopefully ones with large TTLs) hopefully not the whole purpose of "emtpy zones" is to avoid *any* recursion, in the past you had to create all that empty zones at your own to reach that goal 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: Future of BIND's built-in empty zone list
On May 14 2015, I wrote: Now that RFCs 7434 & 7435 have been published, how do ISC see the future ... That should be 7_5_34 & 7_5_35 of course. Curses. -- Chris Thompson Email: c...@cam.ac.uk ___ 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
Future of BIND's built-in empty zone list
Now that RFCs 7434 & 7435 have been published, how do ISC see the future of the seemingly ever-expanding built-in empty zone list in BIND? One possibility that seems plausible to me is to add EMPTY.AS112.ARPA to the list now, and remove existing entries if and when the corresponding names in the public DNS acquire DNAMEs pointing to that (hopefully ones with large TTLs). -- Chris Thompson Email: c...@cam.ac.uk ___ 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
