Re: Question about some oddities in the logs
On 02/22/11 01:41, Eivind Olsen wrote:
Hello. I've recently put into production a new recursive nameserver, and
decided to take a look in the logfiles (the old servers didn't have
logging enabled so I can't really compare the current logs with whatever
the old ones would have been).
I understand most of the entries in the logs + statistics, but there's a
couple of things I'm not sure about - my hope is that someone here can
shed some light on these, and perhaps also tell me if it's expected to see
these in the wild.
The nameserver is running BIND 9.7.2-P3 btw, and yes I know 9.7.3 is out -
it will be upgraded soon.
We're not talking about query logging btw, only a fairly simple logging
channel:
channel default_debug {
file logs/named.run versions 20 size 500m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
Now, to the log entries (I've removed timestamps + IP-addresses):
1) notify: notice: client x.x.x.x#n: notify question section contains no
SOA
Should I be seeing these normally? They only seem to make up a small part
of the full logfiles, still seeing a couple of thousand of these in just a
few days time.
Hmm, looks to me as the box listed as client sends some strange notify
messages. Notify normally should contain SOA, so that receiving NS can
tell if it has outdated zone or no. These don't. What (regarding DNS of
course) is on those machines?
2) security: info: client x.x.x.x#n: query (cache) './A/CH' denied
Not many of these either, but they still seemed a bit weird. Could they be
caused somehow by me running a slave of the root . defined as:
zone . IN {
type slave;
file slave/root.zone;
masters {
...a couple of the root-servers.net servers
};
notify no;
};
I wouldn't expect that to be the cause though, as it's defined as class IN
and not CH.
asking for CH TXT version.bind returns bind's version, unless configured
not to do so. Maybe something also asks for A, but I dunno why. Are
these addresses in your network? Then you can tracethem down probably.
Now, the more important part - why would you be running a slave of root?
AFAIK the root servers don't a) allow transfer b) send you notifies, so
you'll be in trouble as soon as anything changes, which means every week
right now, that root is signed. Why is
zone . in { type hint; }
not enough for you?
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about some oddities in the logs
On Tue, 22 Feb 2011 08:59:51 +0100, Torinthiel torinth...@data.pl
wrote:
Hmm, looks to me as the box listed as client sends some strange notify
messages. Notify normally should contain SOA, so that receiving NS can
tell if it has outdated zone or no. These don't. What (regarding DNS of
course) is on those machines?
These come from a variety of IP-addresses, belonging to customers
(we're an ISP). So I don't know what's really on the customers machines.
asking for CH TXT version.bind returns bind's version, unless configured
not to do so. Maybe something also asks for A, but I dunno why. Are
these addresses in your network? Then you can tracethem down probably.
These are again from customers addresses.
Now, the more important part - why would you be running a slave of root?
AFAIK the root servers don't a) allow transfer b) send you notifies, so
you'll be in trouble as soon as anything changes, which means every week
right now, that root is signed. Why is
zone . in { type hint; }
not enough for you?
At least some of the root servers allow transfers. They won't send me
notifies, true. But I don't need that. Currently the root zone has a
refresh value of 1800 seconds and expire = 604800 seconds, so my slave
servers will check the root for updates often enough.
One advantage is that we can now instantly reject queries for things
like eivind.local. instantly without having to ask the root servers
where local. is served.
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about some oddities in the logs
Dnia 2011-02-22 13:29 Eivind Olsen napisał(a):
On Tue, 22 Feb 2011 08:59:51 +0100, Torinthiel torinth...@data.pl
wrote:
Hmm, looks to me as the box listed as client sends some strange notify
messages. Notify normally should contain SOA, so that receiving NS can
tell if it has outdated zone or no. These don't. What (regarding DNS of
course) is on those machines?
These come from a variety of IP-addresses, belonging to customers
(we're an ISP). So I don't know what's really on the customers machines.
If your clients should send you notify messages (e.g. you host their
secondary DNS, while they have the primary), and if there are no other
symptoms of malfunction, I'd ignore it. they have no reason to send you
notifies, then maybe you can ask them why are they sending it in the first
place (assuming there's someone worth talking to). But still, I think it's
safe to ignore.
asking for CH TXT version.bind returns bind's version, unless configured
not to do so. Maybe something also asks for A, but I dunno why. Are
these addresses in your network? Then you can tracethem down probably.
These are again from customers addresses.
I'd ignore it. If someone thinks otherwise, please step up.
Now, the more important part - why would you be running a slave of root?
AFAIK the root servers don't a) allow transfer b) send you notifies, so
you'll be in trouble as soon as anything changes, which means every week
right now, that root is signed. Why is
zone . in { type hint; }
not enough for you?
At least some of the root servers allow transfers. They won't send me
notifies, true. But I don't need that. Currently the root zone has a
refresh value of 1800 seconds and expire = 604800 seconds, so my slave
servers will check the root for updates often enough.
One advantage is that we can now instantly reject queries for things
like eivind.local. instantly without having to ask the root servers
where local. is served.
Do these happen often enough to warrant such a setup? Ok, it looks it will
work, but you are trading a few (asuming few such TLDs) *possible* queries
per day, for a full zone transfer every few days.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Question about some oddities in the logs
Hello. I've recently put into production a new recursive nameserver, and
decided to take a look in the logfiles (the old servers didn't have
logging enabled so I can't really compare the current logs with whatever
the old ones would have been).
I understand most of the entries in the logs + statistics, but there's a
couple of things I'm not sure about - my hope is that someone here can
shed some light on these, and perhaps also tell me if it's expected to see
these in the wild.
The nameserver is running BIND 9.7.2-P3 btw, and yes I know 9.7.3 is out -
it will be upgraded soon.
We're not talking about query logging btw, only a fairly simple logging
channel:
channel default_debug {
file logs/named.run versions 20 size 500m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
Now, to the log entries (I've removed timestamps + IP-addresses):
1) notify: notice: client x.x.x.x#n: notify question section contains no SOA
Should I be seeing these normally? They only seem to make up a small part
of the full logfiles, still seeing a couple of thousand of these in just a
few days time.
2) security: info: client x.x.x.x#n: query (cache) './A/CH' denied
Not many of these either, but they still seemed a bit weird. Could they be
caused somehow by me running a slave of the root . defined as:
zone . IN {
type slave;
file slave/root.zone;
masters {
...a couple of the root-servers.net servers
};
notify no;
};
I wouldn't expect that to be the cause though, as it's defined as class IN
and not CH.
3) And finally, in the normal statistics file, I see mention of some
RESERVED counters, but I haven't found any corresponding mention in the
logfiles.
For example, the Incoming Requests section lists the number of QUERY,
IQUERY, UPDATE etc, but it also lists a small number of RESERVED13 and
RESERVED14. The Incoming Queries lists a couple of RESERVED0, and
Outgoing Queries lists some RESERVED0 as well.
Should I expect to see these out in the wild? Or should I only really
worry if they're listed in bigger numbers?
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
