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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mathew Ian Eis
Sent: Friday, January 29, 2016 5:56 PM
To: Mark Andrews
Cc: bind-us...@isc.org
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....@nau.edu
(928) 523-2960
-----Original Message-----
From: <bind-users-boun...@lists.isc.org> on behalf of Mark Andrews
<ma...@isc.org>
Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr <garycarr...@gmail.com>
Cc: "bind-us...@isc.org" <bind-us...@isc.org>
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,
>etc.
>
>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
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>_______________________________________________
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>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
bind-users@lists.isc.org
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
