Note that there are additional considerations if there are any descendant
(child, grandchild, etc.) zones of intra.example.net. If "type forward" is
specified in the intra.example.net zone definition, and nothing defined below
that, then recursive queries will continue to be sent, even for names in
descendant zones, to whatever is defined as "forwarders" at that level in the
hierarchy. That may or may not be optimal.
In contrast, "stub" or "static-stub" will query for names in descendant zones
either by sending recursive queries to the global forwarders (if defined and
not suppressed), or, if global forwarders are not defined, or they are
suppressed, the iterative resolution algorithm will be used to obtain the
answer, without using recursion, e.g. following the referral chain down from
the closest-enclosing zone. This will _generally_ result in better performance
and reliability, but is highly dependent on having "good" (reachable, fast,
properly-configured) NS records published at each level of the hierarchy. Note
that forwarding "suppression" can be effected via the idiosyncratic syntax
"forwarders { };" in the zone definition.
Another poster suggested "type slave", i.e. replicating the zone contents via
the standards-defined AXFR/IXFR features of the protocol. While I'm generally a
big fan of zone replication, between different legal entities there is often a
concern about unintentional information disclosure. Also, zone-transfer
permission would have to be granted on the server side, and between BIND and
Microsoft DNS, it can be tricky to work out a mutually-acceptable
authentication method. On the plus side, replicating the zone provides
performance and availability benefits, and replicated zone data is more
resilient against forgery attacks. Please understand that if one opts to
replicate the zone, one's nameserver doesn't have to be *published* for the
zone, i.e. it can be a "stealth slave". It is a common misconception --
especially among Windows types -- that all nameservers holding zone data
authoritatively need to be published as such. If the zone changes frequently,
one should give some th
ought to how quickly those changes replicate, and whether to set up NOTIFY.
Note that "forwarding suppression" might need to be specified for a slave zone
just as it would for a "stub"-type zone.
Whether "type forward", "type slave" or "type stub" is more appropriate,
depends on one's architecture, namespace and security requirements. Within the
2 different "stub" types -- "classic" stub _versus_ "static-stub" -- that's
mostly a manageability/maintainability question (whether one wants the
master/slave interaction to be dynamic, and subject to the
zone-refresh-and-expiration mechanism, or just statically-maintained in one's
named.conf), although the NAT consideration that Andreas pointed out is a valid
one.
- Kevin
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Tony Finch
Sent: Monday, February 15, 2016 5:58 AM
To: Andreas Meile
Cc: [email protected]
Subject: Re: Zone hints for VPN environments
Andreas Meile <[email protected]> wrote:
> The question is: How can I place the ActiveDirectory DNS as forwarder
> DNS server in such a way that it is responsible for a specific DNS zone only?
You very nearly have the right idea, but you are trying to use the wrong zone
type. There are a few options that can work in your situation:
type stub - The "masters" you specify must be authoritative for the zone.
Your server fetches the NS records from the masters and resolves
names for the zone using these NS records. This is a bit like a
hint zone, except hints are only for the root zone.
type static-stub - You specify "server-addresses" or "server-names" which
must be authoritative for the zone. These servers are used
directly, ignoring the zone's NS records. This might work better
than a stub zone if your network disagrees with the zone contents
because of NAT.
type forward - You specify "forwarders" which must be recursive servers
that know how to resolve names in the zone.
There are more details about zone types in the ARM at
http://ftp.isc.org/isc/bind9/9.10.3-P3/doc/arm/Bv9ARM.ch06.html#id2595082
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
Biscay: Northeast 6 to gale 8, decreasing 4 or 5 later. Very rough or high,
becoming rough or very rough. Showers. Good, occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
