Need pointed in the right direction intranet DNS's

[Kevin Darcy]

baltoinfo wrote:
> That was pretty deep...
> The ip address are made up to protect the innocent.
> In a nut shell I think I need to do is a split dns that Bill mentioned
> above.
> Basicly everyone here in on the example.com however we have addresses
> that
> are not in the corp. dns server so we(my lab) we have our own dns
> server. All
> I want to do is to forward any request that I don't have a entry for in
> my dns to the corp
> dns.
>   
Well, if you're running an example.com zone that's different than the 
corporate example.com zone, then you're out of luck. BIND doesn't 
support any form of "failover forwarding", where it forwards on any name 
that isn't found within its own zone(s). You'd probably want to put your 
lab stuff under a subzone of example.com, or some completely different 
domain.

As for setting up your BIND instance to be able to resolve names from 
the corporate server(s), I'm sorry you found my previous post too deep, 
but basically, if your corporate folks are already running an internal 
root zone, and all of the domains you're interested in resolving are 
properly delegated from the namespace "tree", then you should just need 
to get the appropriate root server names and addresses from them, and 
populate a "hints" file with that data. Done.

If on the other hand, they're not running an internal root zone, or in 
cases where domains you care about aren't properly delegated from that 
namespace, then you need to do some sort of "delegation overrides" 
(zones defined as slave, stub or forward), and perhaps you should 
re-read the FAQ, because it explains some of the caveats of delegation 
overrides, and outlines some of the reasons why you might pick one zone 
type over the others for your overrides.

                                                                         
                        - Kevin

> On Oct 12, 6:11 pm, Kevin Darcy <k... at daimlerchrysler.com> wrote:
>   
>> 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 ...
>>
>> read more »- Hide quoted text -- Show quoted text -
>>     
>
>
>
>
>
>