separation of authoritative and recursive functions on internal networks

Mathew Ian Eis Mathew.Eis at nau.edu
Fri Jan 29 22:56:21 UTC 2016


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 nau.edu
(928) 523-2960








-----Original Message-----
From: <bind-users-bounces at lists.isc.org> on behalf of Mark Andrews <marka at isc.org>
Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr <garycarr100 at gmail.com>
Cc: "bind-users at isc.org" <bind-users at 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: marka at isc.org
>_______________________________________________
>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


More information about the bind-users mailing list