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