separation of authoritative and recursive functions on internal networks

Darcy Kevin (FCA) kevin.darcy at
Fri Jan 29 23:58:26 UTC 2016

Why not? Data obtained from the recursive function will never outrank authoritative data of a master or a slave. See the "Data Ranking" section of RFC 2181. AFAICT, it's been a *very* long time since BIND, or any other DNS implementation, has accidentally got those ranking rules wrong and given preference to cached data.

The main theoretical concern about mixing recursive and published-authoritative functions on the same nameserver instance, would be that the recursive functions -- which tend to be rather variable and unpredictable -- might take up too much resources and thus interfere with the published-authoritative functions of the same instance. But that's actually a reason to have *more* NS records (to spread out the load, and to provide sufficient failover capability in case one node gets overloaded, at any particular time), not an argument to leave nodes *out* of the NS records. Diversity is a good thing, and nameserver-selection failover tends to be very quick.

A better reason to limit the number of NS records is that, at a certain point, your Authoritative Section on DNS responses may -- if EDNS0 is not ubiquitous -- grow packet sizes to the point that they cause TCP retries. This is especially likely when slaving Active Directory zones, since AD's recommended practice is for *every* domain controller to run DNS, and the default behavior, at DC promotion time, is to register the DC in the NS records of the domain, if it's running DNS.

A much less likely reason for limiting the NS records of a zone is if one wants to "shape" the traffic flows of queries and (potentially) Dynamic Updates, because, say, some links are a lot more expensive than others (by "expensive" I mean in an economic sense, not in terms of latency, since the nameserver-selection algorithm already takes latency into account). But, given that DNS traffic tends to be a small fraction of overall traffic, this concern is not likely to be a factor.

RFC 2182 recommends 3 NSes per zone, but that RFC was written in 1997, and oriented towards Internet-facing nameservers, at a time when the Internet wasn't nearly as geographically-diverse as it is today. Around here, as a somewhat-large, geographically-diverse enterprise, we tend to have 8-ish NSes for our internal zones, plus or minus a few, depending on how "localized" the zone is. For the Internet-facing stuff, we have less NSes, but they're all VIPs of some kind, backed by multiple devices each. By implementing load-balancing, Anycast, or some combination of the two, it's possible to make a zone highly available without exploding the number of NS records published for it.

											- Kevin

-----Original Message-----
From: bind-users-bounces at [mailto:bind-users-bounces at] On Behalf Of Mathew Ian Eis
Sent: Friday, January 29, 2016 5:56 PM
To: Mark Andrews
Cc: bind-users at
Subject: Re: separation of authoritative and recursive functions on internal networks

Howdy Mark,

Can you please clarify the best practice for this?

> Recursive servers (honouring RD=1) however can be authoritative for zones.

In this context of "authoritative", do you mean that they can be fully functional slaves and have a complete copy of the zone information?

I would imagine you would still not want such recursive servers to be truly authoritative (e.g. listed in the NS records for the zones), correct?

Thanks in advance,

Mathew Eis
Northern Arizona University
Information Technology Services
mathew.eis at
(928) 523-2960

-----Original Message-----
From: <bind-users-bounces at> on behalf of Mark Andrews <marka at>
Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr <garycarr100 at>
Cc: "bind-users at" <bind-users at>
Subject: Re: separation of authoritative and recursive functions on internal	networks

>Authoritative servers (listed in NS records) shouldn't be recursive.
>This prevents leakage of cache data.  This provide consistent answers.  
>The server also doesn't have to decide what type of answer to give 
>(recursive vs authoritative).  Glue doesn't get overridden by answers, 
>Recurive servers (honouring RD=1) however can be authoritative for 
>zones.  This proves robustness in the presence of link failures.
>Faster than ttl expiry of local zone changes (provided that notify 
>messages are sent).
>Unfortunately this has become strict seperation lore which really 
>wasn't ever the intent.
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at
>Please visit to 
>unsubscribe from this list
>bind-users mailing list
>bind-users at
Please visit to unsubscribe from this list

bind-users mailing list
bind-users at

More information about the bind-users mailing list