Need pointed in the right direction intranet DNS's
Kevin Darcy
kcd at daimlerchrysler.com
Thu Oct 12 22:11:16 UTC 2006
baltoinfo wrote:
> I've been banging my head with this one.
> My setup.
>
> Lab1 1 DNS Server bind9.3.1/linux witha zone xxx.com on a
> 192.168.99.0/24 network
> Lab2 1 DNS Server bind9.3.1/linux witha zone xxx.com on a
> 192.168.1.0/24 network
>
> Corp. DNS on 192.168.77.0/24 network which has the complete company DNS
> names.
>
> Both Lab1 and Lab2 DNS work fine with what ip/names I've added, however
> I can't get the two Labs to query nor send a query to the main corp
> dns.
>
You haven't really provided enough information about your environment,
but I can lay out some options and possibilities for you...
First of all, it's obvious that we're not talking about pure Internet
DNS here. A nameserver in the 192.168.77.0/24 range is never going to be
an Internet DNS server (see RFC 1918). So at some point there must be an
"override", either at the very highest level, i.e. you have your own
internal root, or at the level of the specific zones you're having
trouble resolving, or some place in between. If you're running an
internal root, and if all of the zones in question are properly
delegated from that internal-root structure, then the solution to your
problem could be as simple as configuring your DNS servers with the
appropriate "hints" file, with the internal-root-server information in
it. Then your DNS servers can just follow the normal
iterative-resolution mechanism, down from the internal root, and resolve
the names.
Alas, DNS issues are rarely that easy to solve :-) Chances are your
override is at a lower level, or perhaps you have an internal root, but
for whatever reason the zones you're interested in aren't properly
delegated from the namespace. What you need in your named.conf in either
case are explicit definitions -- "delegation overrides" -- for each zone
of interest (or at least the apex zone of each _domain_ of interest, see
the discussion below about descendant subzones). We get questions that
reduce to "delegation override" discussions quite often around here, so
here is my attempt at an FAQ on the subject (sorry about the length, I
need to figure out a way to edit this down):
Q: I need to resolve names in a particular "special" zone, let's call it
example.com, but the delegations for example.com either don't exist at
all, exist but point me to servers that I can't reach, or point to
servers which serve the wrong "version" of the zone (e.g. the external
rather than the internal version of example.com). Obviously I can't use
delegations normally in this case, and need to "override" them somehow.
How do I proceed?
A. The first step is to identify servers which can provide answers from
the "correct" version of example.com. Let's call these the "source"
servers . How you determine these servers is outside the scope of this
FAQ: it is assumed you have some sort of special business, contractual
or organizational relationship with the owners of example.com and/or the
maintainers of the "correct" version of it; they should be able to tell
you what and where the source servers are.
Once you've identified the source servers, verify that your DNS servers
can actually get the proper responses for queries of example.com names,
from those servers. It may be the case that some of your DNS servers can
get those responses, and some cannot; we'll refer to this as a
"split-connectivity" situation. Your solution in that case is a "tiered"
approach where you to try to set up one or more of your DNS servers,
which have direct connectivity to the source servers, as source servers
themselves (first tier), which can then be used by the less-connected
DNS servers in your environment (second tier). (More than 2 tiers are of
course possible, but each tier implies query resolution delay and
possible points of failure).
Also, look at the responses from the source servers and check whether
the AA (Authoritative Answer) bit is set in the headers. Source servers
which answer authoritatively give you more options, as discussed below,
and should generally be preferred over source servers which do not
answer authoritatively. If none of the source servers answer
authoritatively, then your *only* option is to set up example.com as
"type forward". If at least one of them answers authoritatively, then
you have the additional options of "type slave" or "type stub". Each
zone type has pros and cons; some have prerequisites. We'll look at each
in turn:
_Slave_.
Description: Maintain a full, replicated copy of the zone on
your nameserver using the AXFR and/or IXFR extensions to the DNS
protocol, and optionally, the NOTIFY extension, which triggers
replication when there is a change at the source. Your nameserver
considers itself "authoritative" for the zone.
Prerequisites: the source servers must be authoritative for
the zone and permit you to perform zone transfers. Since zone transfers
mandate the use of TCP, that needs be properly configured in any
intervening firewalls. You'll need enough memory and disk space to be a
slave for the zone, and if you specify that you want to store the zone
data in a backup file (highly recommended), the ID under which you run
the "named" process as, needs to have permissions to write to the
zonefile directory and/or the backup file.
Pros: a) offers maximum redundancy, allowing resolution of all
names in the zone even if connectivity to the source servers is lost (up
until the time that the zone expires, which is usually on the order of
days or weeks), b) may give better performance, if the records that your
clients are looking up most have low TTLs yet don't change frequently
(if they do change frequently, it's probably because the destination is
using dynamic, DNS-based load balancing, and by making yourself a slave
for the zone you might be defeating that mechanism somewhat, so tread
carefully), c) since this makes your nameserver authoritative for the
zone, it gives you more options for having it play the role of a source
server in a split-connectivity environment.
Cons: a) In terms of resource usage, both local and network
resources, slaving is often inefficient/overkill: with respect to local
resources, being a slave takes up memory, CPU and disk for records in
the zone that your clients may not even care about, and also adds
incrementally to your nameserver's startup workload; in terms of network
resources, the efficiency or inefficiency of slaving depends on a
variety of factors, including the size of the zone, the REFRESH
settings, how often the zone changes, whether IXFR (incremental
transfer) is in effect, etc., but the calculation often shows it to be
more expensive than the stub or forwarding options, b) if the
administrators of the source servers insist on listing your slave in the
NS records of the zone (i.e. making you a "published" rather than a
"stealth" slave), then you are likely to attract possibly unwanted query
traffic from other resolvers/nameservers in the environment, c)
visibility of changes to the zone may be slow if you are a stealth
slave, unless example.com's REFRESH time is small (which could have a
deletrious effect on resource usage), or your server is added to the
"also-notify" list (or the non-BIND equivalent) on the source server(s)
(also-notify shouldn't normally be required for _published_ slaves,
since they get NOTIFYs by default)
_Stub_.
Description: Replicate only the NS and SOA records of the zone. Your
server is not considered "authoritative" for the zone, since it does not
maintain a full copy of it.
Prerequisites: the source servers need to be authoritative for the zone.
Pros: a) Lightweight on local resources (only the NS and SOA records
of the zone are stored on disk and loaded into memory initially),
Cons: a) since your server is not considered authoritative for the
zone, your split-connectivity options are very limited: other DNS
servers can only use you to resolve example.com names by forwarding to you.
_Forward_.
Description: Send all queries for the zone (and all descendant
zones, if not explicitly defined), for which the answer is not available
in cache, as recursive queries to the source servers. Your server is not
considered authoritative for the zone.
Prerequisites: none.
Pros: a) Lightweight on local resources (no records of the zone are
stored on disk or loaded initially),
Cons: a) possibly-inefficient handling of descendant subzones (see
below), b) since your server is not considered authoritative for the
zone, your split-connectivity options are very limited: other DNS
servers can only use you for resolution of example.com names by
forwarding to you, thus creating a "forwarding chain", which is
generally considered a bad practice, c) in some versions of BIND, the
forwarder-selection algorithm is not adaptive, but proceeds sequentially
through the list of forwarders: these versions do not perform well when
the first forwarder in the list is down or unavailable, d) if the source
servers do not honor recursion for your DNS server(s), then this will
impede your ability to resolve names in descendant subzones (see below)
unless they happen to also be authoritative for those as well, or, even
if there are no descendant zones, or the source servers are
authoritative for all of them, likely to generate log warnings about
"forwarder does not support recursion" (or words to that effect).
_Descendant Subzones_
In addition to example.com itself, if there are any descendant subzones
(blah.example.com, foo.bar.example.com, etc.) for which the source
servers are not authoritative, you should consider how those will be
handled. In the case of a "type slave" or "type stub" example.com
definition, the default behavior will be to resolve names in those
subzones directly from the delegated nameservers (if forwarding is
defined at a higher level in the hierarchy, or globally, then this
alters the default behavior and defining "forwarders { };" in the slave
or stub zone definition of example.com will be necessary to get the
behavior back to the default for the example.com branch of the
namespace). If the delegated nameservers are unreachable or give the
"wrong" version of the descendant zone, then you'll need to repeat this
whole line of consideration (i.e. what and where are the source
servers?, do I have connectivity to the source servers?, etc.) in each
case. If example.com is defined as "type forward", then the delegations
of descendant zones will, by default, be ignored, with the source
servers being used for everything in that branch of the namespace. This
then imposes an extra requirement that the source servers honor
recursion for your DNS server(s), which might not always be the case.
Even if it works, you'll need to evaluate on a case-by-case basis
whether this is appropriate or not. It might result in inefficient
and/or unreliable operation, since the delegated nameservers for a
particular descendant zone may be "closer" to your servers than the
source servers of example.com, or the connectivity between the sets of
servers (i.e. between the example.com source servers and the delegated
servers for the various descendant zones) may be less reliable than your
connectivity to either set considered separately. Therefore, even though
"type forward" makes it "easy" to deal with descendant zones in the
usual case, it might be better from a performance and reliability
standpoint to perform an "override" for one or more of those descendant
zones.
- Kevin
More information about the bind-users
mailing list