Re: Need pointed in the right direction intranet DNS's - DNS

This is a discussion on Re: Need pointed in the right direction intranet DNS's - DNS ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Need pointed in the right direction intranet DNS's

  1. Re: Need pointed in the right direction intranet DNS's

    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



  2. Re: Need pointed in the right direction intranet DNS's

    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.

    On Oct 12, 6:11 pm, Kevin Darcy 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 -




  3. Re: Need pointed in the right direction intranet DNS's

    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 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 -
    >>

    >
    >
    >
    >
    >
    >




+ Reply to Thread