Zone hints for VPN environments

Tue Feb 16 00:42:27 UTC 2016

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 thought 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: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Tony Finch
Sent: Monday, February 15, 2016 5:58 AM
To: Andreas Meile
Cc: bind-users at lists.isc.org
Subject: Re: Zone hints for VPN environments

Andreas Meile <mailingliste at andreas-meile.ch> 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  <dot at dotat.at>  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
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users