On 1/2/2012 5:42 AM, Matus UHLAR - fantomas wrote:
On 21.12.11 19:21, Peter Andreev wrote:
All these servers are slaves. They don't send notifies.
2011/12/21 Matus UHLAR - fantomas <uh...@fantomas.sk>:
they do, unless you have turned it off...
On 22.12.11 11:54, Peter Andreev wrote:
Of course I turned it off, it's normal practice for slaves, I assume.
even sending notifies by slaves can have a reason. for example, other
slaves not getting notifies from master...
Do you think if server needed to resolve something, and you would
disable
it, it would work better? I think just the oposite. If a server does
lookups
only when needed, then disabling required lookups would make it not
working.
I think that if server is authoritative - and - slave-only it should
use system resolver rather than querying by itself.
BIND will not use system resolver. BIND is the resolver. Relying on
other resolver could cause troubles. If BIND does not need to resolve,
it will not. If it needs, don't block it.
I agree with Matus. BIND should be as self-sufficient as possible, and
not make any assumptions about the capability of and/or the data it
expects to get from the system resolver, which might be configured to
look at a completely different DNS namespace, or be configured with
non-DNS resolution methods, be broken with respect to IPv4/IPv6
capabilities, address sorting, etc. There's lot that can go wrong when
you make one subsystem (BIND-based DNS) dependent on another (system
resolver, however that's set up, if it's set up at all). BIND already
has ways to resolve names, and many different ways to precisely control
how it does that, so it shouldn't be necessary to rely on a completely
different subsystem for that function.
Now, what are your real complaints about an authoritative-only
nameserver making "internal" queries? Looking back through the thread, I
think there are two:
1) That internal lookups are generated when sending NOTIFYs. Do you
actually need to send those NOTIFYs, or are you just leaving things with
the default configuration (which follows the RFC 1996 algorithm of
looking at the contents of the zone's NS records and its SOA.MNAME)? If
you need those NOTIFYs at all, I expect that you could suppress the
associated lookups with a combination of "also-notify" and "notify
explicit". Then BIND only has a list of IP addresses to which to send
NOTIFYs and I can't (offhand) see any reason for it to generate
"internal" lookups. I haven't tested this theory, but it shouldn't be
hard to do. Another thing to consider: even with the default NOTIFY
behavior, named shouldn't need to generate lookups for any of the names
associated with the NOTIFYs which are in zones for which it is
authoritative. E.g. if you're authoritative for example.com and
ns1.example.com is a name within that zone, then you shouldn't need to
generate a lookup for that name if you want to send a NOTIFY to it.
Moreover, since NS targets tend to "cluster" within groups of zones
under common administrative control, it should only be a fairly small
minority of NS targets which require internal lookups for NOTIFY
purposes. Is this really a problem then?
2) "upwards referrals". If your recursion-disabled nameserver is
configured to respond to queries outside of its authoritative zones,
then the typical response would be an "upwards referral" to the root
zone. But to give good, current information about the root zone, when
the root zone is explicitly or implicitly defined with only "hints", a
"priming" query needs to be made when named starts up (since "hints" are
only "hints", not the real data, which is obtained by querying the
roots). Someone mentioned defining your own root zone authoritatively
with localhost as the only root nameserver. But that's a really bad idea
if you're giving out upwards referrals to arbitrary Internet resolvers.
You could poison the cache of some really old, broken nameserver. The
link that David Forrest gave to a DNS-OARC webpage pretty much runs down
the whole "upwards referral" issue, and I recommend you read it. You
could combine defining your own root zone authoritatively (which will
suppress the priming query), with carefully controlling access to that
zone (as described on that webpage) so that no upwards referrals are
given. I wouldn't recommend populating that root zone with "garbage"
(such as localhost, for example); I'd put real root-zone information in
there, just in case the ACLs in named.conf get accidentally reconfigured
some day (perhaps by whomever inherits your config). That root-zone data
gets stale over time, of course, but it takes many many years for it to
become completely invalid, and if you're concerned about that, you could
write a simple script to do a root zone query periodically (e.g.
monthly) and refresh the contents of the zone file. Or, you could just
let ISC do the work of compiling the latest root-zone data into each
version of BIND they put out, and not worry so much about an occasional
priming query.
I think the main issue here is that you got a user problem report of
"bad DNS data" without any specifics or reproducibility, and you're
just, frankly, grasping at straws trying to find a explanation and/or a
solution. I can assure you, there are many thousands of sites that allow
their "authoritative-only" BIND nameservers to perform "internal"
queries, and never have a problem with "bad data" being presented
randomly to users. Conversely, this is the first time I've heard anyone
complain that the "internal" queries of an "authoritative-only" BIND
nameserver might possibly, potentially have led to some sort of data
inconsistency problem. So, unless you can actually identify a real
problem here, I'd stop worrying about these "internal" queries.
Eliminating them seems more a classic case of "a solution looking for a
problem" rather than the other way around, and in order to "fix" things,
you may end up making your configuration so twisted and convoluted,
chances are you'll inadvertently introduce other, real problems that
will affect your users negatively. Sometimes the wisest choice an IT
and/or Network admin can make is to leave messy "imperfect" behavior alone.
There are other explanations of "bad DNS data" besides BIND as well. You
need to look at the entire environment, every component, every step in
the process. In most cases I've run across this symptom, it's because
certain flavors of VPN software violate one of the fundamental
principles of DNS resolution -- they fail over to another resolver when
they get an NXDOMAIN or NODATA response (which they shouldn't do, since
NXDOMAIN/NODATA are perfectly-valid responses in and of themselves).
They then cache data from that failover lookup which can have a negative
effect on future lookups. This is further exacerbated if their
"failover" resolver(s) is/are run by evil ISPs that do "NXDOMAIN
redirection" (Google that if you're not familiar with the
concept/practice). So, you need to look further afield for the real root
cause of the problem, rather than obsessing over the fact that an
"authoritative-only" BIND instance, in the absence of a lot of custom
configuration, still generates a few queries here and there for internal
purposes, and thus is not *perfectly* "authoritative-only".
- Kevin
_______________________________________________
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
