Hi!

I'm using Bind to provide some friendly names for my local services,
such as: svn.localhost, php.localhost (for php prjects), java.localhost
(for JavaEE) and so on. I have no trouble to set up this behave. But
also I wants to study how DNS and Bind works, cause I'm studding
computer science. And I have a problem.

My Bind server is chrooted, and there is no any special options set
(such as: -c). Bind configuration should be read form /etc/bind/ (as its
chrooted, for me: /var/bind9/chroot/etc/bind) and this is set.

options {...} are most default...

  If I add 'recursion no;' statement to options, Bind behave as
Authority-only server. So it no answer for queries like: dig @127.0.0.1
+norecurse ns. Its understandable for me. dig @127.0.0.1 ns is rq so it
will be refused also.

If I change 'recursion no;' to 'recursion yes;' dig @127.0.0.1
+norecurse ns will be refused, but dig @127.0.0.1 return answer
(recursive query).

Its all ok, but... From where Bind gets informations about root zone?

If I comment line 'include "/etc/bind/named.conf.default-zones"' should
not be any informations for about root zones, and my local zones too.
/etc/init.d/bind9 restart
rndc flush
(no cahce?)
But Bind further ehav root zones informations. I suspect that it is
automatically downloaded. I look in tcpdump but I did not discovered any
transfer.
ifdown wlan0 -> from now there is only loopback interface, again bind9
restart, rndc flush.
Bind still knows root zones... My question is why? Is there something
that I don't understand, or something I don't know?

Bind 9.7.3
Linux lex-sclavia 3.0.0-1-686-pae
Debian wheezy (testing)

Thank you for reply.
Luke.

Named has a compiled in set of root hints.  It is used if
    a root zone is not defined in named.conf.

    Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

Whether it means that without hint zone named still can perform
iterative lookups for its internal purposes?

--
--
AP

yes.

--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains?

This fact is really disappointing.
Anyway thank you, Matus, for answer

--
--
AP

well, it's needed for proper functionality. What exactly seems to be
your problem?

Note that
- only clients that are allowed to recurse are able to see date
   the "type hint" zone
- only clients from local networks are allowed to recurse by default.
   You can tune this by configuring the "allow-recursion" option.
--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.

Well, we run a bunch of authoritative-only slave servers and obviously
they don't have to perform any kind of lookups.
Some time ago user complained that one of these slave servers
responses with wrong data. My colleague tried to investigate this
issue, but without any success. Just in case we disabled
"additional-from-cache".
That's why any sort of internal lookups looks very suspicious for me.

--
--
AP

"if a root zone is not defined in named.conf"

I wonder if you really do NOT want to ever hit root zones you could make yur own entry in named.conf that points to localhost for root zone and therby avoid hitting any real root?

If they don't have to, they won't.

Disabling recursion should do the same afaik. However, disabling
additional-from-cache is OK and afaik disabled by default.

server needs to resolve names if it's supposed to send NOTIFY messages.

--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol.

I hope so.

No, it is enabled by default.

All these servers are slaves. They don't send notifies.

So while I'm really confused about described issue, I'd like to not
speculate on it, because it happened only once.
What I don't like at all is the impossibility to disable these
lookups. Of course I can follow Jeff's advice and redirect these
lookups to localhost, but it is not a solution, it only transfers
problem to another area.

Ok, may be I'm a paranoid and worrying about trifles, but news about
compiled in hints astonished me.

--
--
AP

they do, unless you have turned it off...

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.

since it only happened once and you weren't able to find out what
really happened (did you at least make sure your customer is right?),
it should not be an issue to care about this much...
--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

The test shown here may calm you (if it shows refusal): https://www.dns-oarc.net/oarc/articles/upward-referrals-cons[..]

Dave

--
David Forrest
St. Louis, Missouri

David, thank you, I checked and all seems good :).

Of course I turned it off, it's normal practice for slaves, I assume.

I think that if server is authoritative - and - slave-only it should
use system resolver rather than querying by itself.

Where can I find information about what causes queries for internal
duties? If it can be found in ARM, could you please point me to the
right chapter. May be I missed something while reading it. The only
mention I have met is that additional resolving is needed for sending
notifies (And will this resolving be performed in case of list of
slaves' ip addresses is written in named.conf?).

--
--
AP

even sending notifies by slaves can have a reason. for example, other
slaves not getting notifies from master...

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.

Someone other will have to answer this.
--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod

I understood your point, however it differs from mine.

Matus, I'm afraid we won't find consent on this topic. So I offer you
to stop this discussion.
Thank you for suggestions and happy new year!

--
--
AP

I don't see your point now. I'm afraid that you will have to live with
the fact that you can not disable sending queries from BIND when it
needs them, you can only prevent it by configuring BIND (so it will not
need them) or firewall such packets so they will not get outside (which
may break its functionality).

Maybe ISC will patch BIND to use system resolver for internal queries,
but I doubt so. Maybe you can do it but imho it's not worth trying.

Maybe you can set up forward only; and forwarders {}; so BIND will
forward all recursive queries it generates to your recursive servers.

But the way you are trying to get over this, I'm afrait you will fail
and that's what I am trying to tell you.
--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse

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

If the system resolver is good enough for every other application
running on the system, it should be good enough for BIND.

Why not at least allow this as an option?

--
Barry Margolin
Arlington, MA

The system resolver will happily provide answers based upon data from /etc/hosts, YP/NIS, and LDAP which have no relationship to what is in the DNS.

Every other application on the system is probably not a DNS nameserver.  Case in point: should dig use the system resolver for an /etc/hosts entry and pretend that there was an A and PTR record in the DNS?

Regards,
--
-Chuck

+1

Given that there exist today name server solutions that are
authoritative-only, it makes sense that BIND 9 should have a knob to do
this.

Also, consider the potential harm of cache poisoning when the features
are mixed.

Doug

--

    You can observe a lot just by watching.    -- Yogi Berra

    Breadth of IT experience, and depth of knowledge in the DNS.
    Yours for the right price.  :)   http://SupersetSolutions.com/

In that case, you probably shouldn't enable the option.  I'm not even
suggesting that the option be on by default.

Actually, does libresolv really use those other facilities?  
gethostbyname() does, but BIND probably shouldn't use that, because it
loses data like TTLs.

But a DNS nameserver is not the same thing as a DNS client.

Of course not, since the purpose of dig is to test DNS queries and show
the internal details.

--
Barry Margolin
Arlington, MA

My point: I need my servers to answer with authoritative data only. I
need them to not perform anything else. Only "get query - send
authoritative response". Where in this scenario BIND has to resolve
something?
In which scenario (except master & notifies) BIND has to resolve something?

I'm free to replace BIND with another authoritative DNS implementation.

--
--
AP

highly depends on configuration of host.conf or nsswitch.conf, but
afaik hosts are preferred by default on most of systems.

and that is one of reasons why BIND does not (and apparently even
should not) use system libresolv and gethost* functions.

--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

Are we talking about the same libresolv?  I'm talking about functions
like res_query(), which are very DNS-specific.  They return the raw DNS
reply data, including details like TTL.

gethostbyname() is the function that uses nsswitch.conf.

--
Barry Margolin
Arlington, MA

Nowhere. Note that BIND may send upward or root referrals, for clients
that are allowed to view cached data (the hint zone is taken as
cached). Also, bind can send additional data (authoritative or from
cache) when configured so, but won't recursively resolve them.

See description of additional-from-cache and additional-from-auth,
maybe minimal-responses.

I don't know about any.

Yes, you are. but i'd advise you focus on the real problem, if it
exists. Kevin Darcy mentioned that in his response.

--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.

Let me ask this question another way.  How do you plan to block BIND
from making any queries outside the server?  If you want me to log any
queries that I don't answer(refused in the logs), I think the default is
to look up the reverse of the querying IP address.  Do you want to block
that type of traffic also?

Do you want to block this traffic at the application level or in
IPTables?  If you block this traffic via IPTables or an external
firewall, lots of things at the OS level get grumpy.

For instance, I want to attach to the server using VNC or SSH for
maintanence.  By default, they want to do do a reverse lookup of your ip
address before allowing access.  Now you wait for that query to time out
before you can do your work.  That's just a PITA.

And if Bind does want to do any lookups(reverse lookups, go query the
root servers for something), now you are forcing it to timeout rather
than doing the lookup and continuing on it's way.  Very inefficient use
of resources and will cause delays for legit queries.

BIND was designed to be a multipurpose application and as such, it wants
and is happier being able to do lookups as needed.  You are asking for a
specific use case and ISC is not into generating special builds for
special or specific use cases unless you contract with them to build and
maintain your special build of BIND.

Lyle Giese
LCR Computer Services, Inc.

Yep, that's what I done first when problem appeared. Second step was
deleting root.hints to (as I hoped) prevent any further resolving and
caching.

Neither do I. Unfortunately it is not covered in documentation.

--
--
AP

You are absolutely right, BIND is a general purpose DNS server and it
plays its role well. Furthermore BIND is the de facto standard (yes, I
copypasted this phrase from wikipedia). And both these statements are
true.
Unfortunately as I learning BIND more, I understand that it is not
very suitable for my requirements.

--
--
AP

Which are?  I've been trying to understand what the actual problem you are trying to solve might be.

Regards,
--
-Chuck

Of course you wouldn't block DNS queries at the network level, that
messes up everything else running on the machine.

He apparently just wants to ensure that nothing gets into the BIND cache
of an authoritative-only server -- it should truly be
authoritative-only.  If other servers on the machine need to do lookups,
it will use a caching server for this.

--
Barry Margolin
Arlington, MA

I'm not trying to solve any problem. I'm wondering why this thread
grown so big. The only question I have unanswered is where I can find
etc? That's all :)
It was asked in 13th post. May be it's still unanswered because of
unhappy number, I'm not sure.

--
--
AP

See, there's the problem right there. Many of us see the BIND instance
as forming part of an *infrastructure*, not just an *application* that
happens to run on the machine. This distinction isn't just semantic. We
have, for instance, totally separate groups who manage the OS'es of our
servers (including the configuration of the system resolver), versus
those of us in the Networking area who have responsibility for the DNS
infrastructure itself.

Those server folks have strange ideas about name resolution. Strange
enough that sometimes I don't even understand what the hell they are
trying to accomplish. Or, they do know, but I think they indulge the
end-users way too much (don't even get me started on shortname
resolution, for instance, and the ugly hacks we're forced to maintain,
supporting that bad habit).

So no, the system resolver is not "good enough for BIND". Not in my
book. I'm responsible for BIND, I'm not going to stick my neck out
making my subsystem dependent on someone's else's subsystem, when I have
no confidence that they know what they're doing and/or that they're
doing the right things.

Nor do I think it is particularly unusual for the Networking and Server
responsibilities within an organization to belong to different groups,
with different skillsets and competency levels. BIND is good at
resolving names to addresses, so let it do the name resolution, without
creating unnecessary dependencies which may cross organizational and
possibly even trust boundaries. I've already outlined in my previous
message some possible ways to obviate these "internal" queries, along
with the suggestion that maybe at the end of the day it's actually more
trouble than it's worth...

                                                                        
                                                                 - Kevin

In all fairness, lots of folks have strange ideas.  We should start with
standards -- software should be built based on BCPs (peer review rules).  If
those don't meet our needs, we should help to get them updated (good luck, I
know -- many standards bodies have become like political lobbyists)

Maybe it's because I started in networking...  But TCP/IP (or IPv6 these
days) is quite the "subsystem" to avoid.  Really, like it or not, you are
actually responsible for understanding interactions with "subsystems" your
managed system must interact with.  ;-)

That's the problem.  Such suggestions won't ever become BCPs, since they
aren't easily justifiable to business minds.  Granted, personal preferences
are always welcome...but "more trouble than it's worth" and "business
priority" or even "POLA" don't jive.

--
Don't worry about avoiding temptation -- as you grow older, it starts
avoiding you.  -- The Old Farmer's Almanac

If you want named to be authoritative only set "recursion no;" or
"allow-recursion { none; }" or "allow-query-cache { none; };" and
no data will be returned from the cache.  allow-recursion and
allow-query-cache cross inherit from each other.

If you only want master zones to send notify messages then set
"notify master-only;".

If you want named to only use the same nameservers as the system
uses then set "forward only; forwarders { <list from resolv.conf>; };".
Named does not read resolv.conf though the tools do.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

Thank you, Mark, these things was done long time ago. Is there any
documentation related to BIND's internals?

--
--
AP

Yes, unfortunately we sometimes have to rely on systems and sub-systems
maintained by others.  But in order to stick to the Principles of Least
Astonishment, it is easier to rely on those systems under our own control.
Otherwise someone else will astonish us with their "brilliance".

I manage the DNS and the spam filters here.  Without warning (I know a
separate issue), the network was changed causing problems between the spam
filters and the DNS servers.  Took me 2 days to figure out what was casing
email to fail.

I cannot chose what network to use.  I can choose what resolver to use.  

Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

Yes, I've mistaken those two.

However, it comes to another reason why BIND should not use system
resolver: If someone messes it up (e.g. puts bad entry to /etc/hosts), it
could mess up DNS.

Replicating configuration errors to DNS may also break things.

In fact, it may cause similar problems than Peter Andreev is trying to
avoid.  And it may cause them independantly on the nameserver used.

--
Matus UHLAR - fantomas, uhlar*******/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !