Re: separation of authoritative and recursive functions on internal networks

[Grant Taylor]

On 02/07/2016 04:12 PM, Reindl Harald wrote:

Warn SOA MNAME entry WARNING: SOA MNAME
(tncsrv06.tnetconsulting.net) is not listed as a primary nameserver at
your parent nameserver!


I know that this is a late reply, but I just ran across something that 
relates to this:


Per section 6.8 of "DNS Delegation Requirements" (Internet-Draft) 
(http://www.ietf.org/id/draft-wallstrom-dnsop-dns-delegation-requirements-00.txt) 
states the following:



6.8. SOA MNAME MUST be authoritative for the zone


Check.


The hostname of the MNAME field may or *may not be listed among
the delegated name servers*, but SHOULD still be authoritative
for the zone. MNAME may be used for other services, e.g., DNS
NOTIFY [RFC1996] and DNS Dynamic Updates [RFC2136].


So, per current Internet-Draft for delegation, the SOA MNAME is not 
required to be listed as a NS.



It should be noted that there are no formal requirement that the
name server listed in the SOA MNAME is reachable from the public
Internet. Because of this, it may be difficult to implement a
reasonable test for this requirement.




--
Grant. . . .
unix || die
___
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

Re: separation of authoritative and recursive functions on internal networks

[Grant Taylor]

On 02/07/2016 04:12 PM, Reindl Harald wrote:

define OK


Will it cause any problems if the slave server is not listed as an NS?


for internal use NS records don't matter at all because the
only thing which matters is that the machines listed in /etc/resolv.conf
respond correctly


I think I understand the intent behind what you are trying to say.  (NS 
(delegation) records aren't needed for internal zones -as long as- 
clients that use them are configured correctly.)


I do question the scalability of that intent.  If I expand the SOHO 
analogy to be a larger corporate + multiple branch offices scenario, I 
can see how internal delegation w/ associated NS records would be needed.



if it comes to the internet - it makes no sense have nameservers which
are not listed as NS records


I disagree.


http://www.intodns.com/

Warn SOA MNAME entry WARNING: SOA MNAME
(tncsrv06.tnetconsulting.net) is not listed as a primary nameserver at
your parent nameserver!


My master name server, tncsrv06.tnetconsulting.net, is internet 
accessible, but it is not listed as a NS because I want all public 
queries to go through my slaves, ns{1..5}.linode.com.  Yet, people can 
direct queries to my master name server if they have a specific reason 
to do so.


I've previously asked Cricket Lou and Matt Larson, via Mr-DNS, if this 
type of configuration (having an Master Name server not listed in the NS 
records) is a problem and they indicated that it's not 100% ideal, but 
it will not cause any problems as long as the listed NS servers are 
accessible and used for delegation from the parent.  I.e. if your MNAME 
server is behind a firewall that will only allow the slave NS servers to 
communicate with it.


What was your intent in pointing that out?  That has nothing to do with 
my original question.


Further, I don't see any response to my question, mixing recursive and 
authoritative resolvers in a SOHO scenario that is not internet accessible.




--
Grant. . . .
unix || die
___
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

Re: separation of authoritative and recursive functions on internal networks

[Grant Taylor]

I know that this is an older thread, but I've been holding onto it for a 
while with the intent of asking a related question.


On 08/10/2015 12:12 PM, Mark Andrews wrote:

Authoritative servers (listed in NS records) shouldn't be recursive.


I'm taking this to mean servers that have zones (properly) delegated to 
them via glue records.  Correct?



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.


This makes sense, especially in light of other comments in the thread 
about older name server daemons having bugs that could be problematic to 
this process.



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


This sort of flies in the face of the first statement, unless this is a 
reference to configurations like recursive servers also being slaves 
for, thus authoritative for, one or more zones -AND- not being listed in 
an NS record.


Does being a slave for a zone imply that a server is also listed as an 
NS?  Or is it considered "okay" for a server to slave a zone without 
publishing that it does so?



This proves robustness in the presence of link failures.
Faster than ttl expiry of local zone changes (provided that notify
messages are sent).


I presume you are referring to the slave zone expiration timer, not 
normal record TTLs.



Unfortunately this has become strict seperation lore which really
wasn't ever the intent.


*nod*

Hence why I'm asking my related question.

Is it considered "okay" to mix the authoritative and recursive roles for 
a SOHO DNS server w/ a local, non-internet facing, zone?  I.e. ".local" 
for Bonjour (et al) or "home.example.net".


I've been pondering the "separation lore" in this context for a while 
and still have not really settled on an acceptably good solution.  - 
I've felt that having separate recursive and authoritative servers in 
such a situation is overkill and overly complex.


I'm curious what people consider best (or at least acceptable) practice 
in this type of SOHO environment.




--
Grant. . . .
unix || die


P.S.  For added fun, throw AS112 and / or root zone slave into the mix. 
 }:-)

___
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

Re: separation of authoritative and recursive functions on internal networks

[Reindl Harald]

Am 08.02.2016 um 00:06 schrieb Grant Taylor:

Does being a slave for a zone imply that a server is also listed as an
NS?  Or is it considered "okay" for a server to slave a zone without
publishing that it does so?


define OK - for internal use NS records don't matter at all because the 
only thing which matters is that the machines listed in /etc/resolv.conf 
respond correctly


if it comes to the internet - it makes no sense have nameservers which 
are not listed as NS records


http://www.intodns.com/

Warn 	SOA MNAME entry 	WARNING: SOA MNAME (tncsrv06.tnetconsulting.net) 
is not listed as a primary nameserver at your parent nameserver!




signature.asc
Description: OpenPGP digital signature
___
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

Re: separation of authoritative and recursive functions on internal networks

[Mark Andrews]

In message <56b7cdfb.5070...@tnetconsulting.net>, Grant Taylor writes:
> I know that this is an older thread, but I've been holding onto it for a
> while with the intent of asking a related question.
>
> On 08/10/2015 12:12 PM, Mark Andrews wrote:
> > Authoritative servers (listed in NS records) shouldn't be recursive.
>
> I'm taking this to mean servers that have zones (properly) delegated to
> them via glue records.  Correct?

I said "listed in NS records".  Glue may / may not need to exist.

> > 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.
>
> This makes sense, especially in light of other comments in the thread
> about older name server daemons having bugs that could be problematic to
> this process.

No.  Just this is ill specified.  That said named attempts to provide
sane answers even when it is performing both rolls.

> > Recurive servers (honouring RD=1) however can be authoritative for
> > zones.
>
> This sort of flies in the face of the first statement, unless this is a
> reference to configurations like recursive servers also being slaves
> for, thus authoritative for, one or more zones -AND- not being listed in
> an NS record.

You can be authoritatative and be listed in the NS record.
You can be authoritatative and not be listed in the NS record.

To be authoritatative the server is configured to server the zone.

The word authoritatative is overloaded in DNS.

> Does being a slave for a zone imply that a server is also listed as an
> NS?  Or is it considered "okay" for a server to slave a zone without
> publishing that it does so?

It's perfectly fine to be a slave for a zone w/o being listed in
the NS records.  You won't get notified by default of changes to
the zone but that can be addressed by configuration and the normal
SOA timers already cover the case where NOTIFY messages are missed.

> > This proves robustness in the presence of link failures.
> > Faster than ttl expiry of local zone changes (provided that notify
> > messages are sent).
>
> I presume you are referring to the slave zone expiration timer, not
> normal record TTLs.

No, I mean normal TTL.  If you are a slave and are getting notify
messages updates happen in seconds, not minutes or hours which are
the usual range for TTL values.

> > Unfortunately this has become strict seperation lore which really
> > wasn't ever the intent.
>
> *nod*
>
> Hence why I'm asking my related question.
>
> Is it considered "okay" to mix the authoritative and recursive roles for
> a SOHO DNS server w/ a local, non-internet facing, zone?  I.e. ".local"
> for Bonjour (et al) or "home.example.net".

.local doesn't have servers.

Home zones generally aren't delegated to so there isn't a need for
seperation of rolls.  Even if they are delegated to the home server
is more likely to be a stealth master so it won't be in the NS
RRset.  And as with almost all rules there are exceptions.

> I've been pondering the "separation lore" in this context for a while
> and still have not really settled on an acceptably good solution.  -
> I've felt that having separate recursive and authoritative servers in
> such a situation is overkill and overly complex.
>
> I'm curious what people consider best (or at least acceptable) practice
> in this type of SOHO environment.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> P.S.  For added fun, throw AS112 and / or root zone slave into the mix.
>   }:-)
> ___
> 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
-- 
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

Re: separation of authoritative and recursive functions on internal networks

[Grant Taylor]

On 02/07/2016 05:54 PM, Reindl Harald wrote:

why?


(I believe I answered your question in the subsequent paragraph.  If not 
let me know and I'll try again.)



that's not a reason for not list one of them as SOA


None of the slaves are the SOA.  (Further, I'm not aware of them having 
been configured for forward any updates, even if I allowed them, to the 
real master.) So listing one of them as the SOA would be a lie.



the salve don't need the SOA because it's typically configured to use
whatever server as master which allows zone transfers, frankly you can
even chain slaves pulling zones from other slaves


I know that slaves don't need (utilize) the SOA.  That's not why I have 
my master listed in the SOA.


I have my master listed in the SOA because 1) it is the actual master 
and 2) I have no reason to lie and put something else.


My master is not listed as an NS because I don't want general queries 
going to it.  Seeing as how I have five other NS servers, I see no need 
to list the master.


Yes, I'm aware that you can chain slave servers.  (Though I would hope 
that you have a good reason for doing so.  Where "good reason" is more 
compelling than just to make some validator that doesn't understand my 
config happy.)



that it's in general a good idea to use validation services and follow them


I'm taking "general" to be the key word.  Namely that it applies to a 
very common configuration.  I consider my configuration to be less than 
common (but not rare).  As such, I have no problem with not following 
this particular suggestion.



the answer is: we are doing that for more than 10 years now


Thank you for your answer.



--
Grant. . . .
unix || die
___
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

Re: separation of authoritative and recursive functions on internal networks

[Grant Taylor]

On 02/07/2016 04:55 PM, Mark Andrews wrote:

This proves robustness in the presence of link failures.
Faster than ttl expiry of local zone changes (provided that notify
messages are sent).


I presume you are referring to the slave zone expiration timer, not
normal record TTLs.


No, I mean normal TTL.


Now I'm confused.  Will you please elaborate on what you meant then?

I interpret "normal TTL" to be the TTL for a given record.  Is that also 
what you mean?


Are you referring to the fact that a caching recursive server will 
expire the TTL before refreshing to see the new / updated zone contents? 
 Compared to the slave server (presumably with properly functional 
notifications) seeing the same new / updated zone contents?



If you are a slave and are getting notify
messages updates happen in seconds, not minutes or hours which are
the usual range for TTL values.


Agreed.

I mis-took your statement about link failures to mean the ability to 
continue serving the zone while the link was down until the zone expired.



.local doesn't have servers.


Um

Please forgive me while I look at many Small Business Server / poorly 
configured networks.


That being said, I'll give you that it's not an official TLD.  (Last I 
looked.)



Home zones generally aren't delegated to so there isn't a need for
seperation of rolls.  Even if they are delegated to the home server
is more likely to be a stealth master so it won't be in the NS
RRset.  And as with almost all rules there are exceptions.


*nod*

Hence my question about how / where SOHO recursive / authoritative 
servers fall into the rule ~> exception.




--
Grant. . . .
unix || die
___
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

Re: separation of authoritative and recursive functions on internal networks

[Reindl Harald]

Am 08.02.2016 um 01:35 schrieb Grant Taylor:

On 02/07/2016 04:55 PM, Mark Andrews wrote:

.local doesn't have servers.


Um

Please forgive me while I look at many Small Business Server / poorly
configured networks.

That being said, I'll give you that it's not an official TLD.  (Last I
looked.)


it is and has a special purpose

https://en.wikipedia.org/wiki/.local


Home zones generally aren't delegated to so there isn't a need for
seperation of rolls.  Even if they are delegated to the home server
is more likely to be a stealth master so it won't be in the NS
RRset.  And as with almost all rules there are exceptions.


*nod*

Hence my question about how / where SOHO recursive / authoritative
servers fall into the rule ~> exception


when you have only internal servers not directly reachable from the 
internet the is no reason that the authoritative nameserver for your 
internal domains is not at the same time the recursive caching server




signature.asc
Description: OpenPGP digital signature
___
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

Re: separation of authoritative and recursive functions on internal networks

[Reindl Harald]

Am 08.02.2016 um 01:00 schrieb Grant Taylor:

On 02/07/2016 04:12 PM, Reindl Harald wrote:

define OK


Will it cause any problems if the slave server is not listed as an NS?


no


for internal use NS records don't matter at all because the
only thing which matters is that the machines listed in /etc/resolv.conf
respond correctly


I think I understand the intent behind what you are trying to say.  (NS
(delegation) records aren't needed for internal zones -as long as-
clients that use them are configured correctly.)


the clients ask your server or not, they are not doing recursion


I do question the scalability of that intent.  If I expand the SOHO
analogy to be a larger corporate + multiple branch offices scenario, I
can see how internal delegation w/ associated NS records would be needed.





if it comes to the internet - it makes no sense have nameservers which
are not listed as NS records


I disagree.


why?


http://www.intodns.com/

Warn SOA MNAME entry WARNING: SOA MNAME
(tncsrv06.tnetconsulting.net) is not listed as a primary nameserver at
your parent nameserver!


My master name server, tncsrv06.tnetconsulting.net, is internet
accessible, but it is not listed as a NS because I want all public
queries to go through my slaves, ns{1..5}.linode.com.  Yet, people can
direct queries to my master name server if they have a specific reason
to do so.


that's not a reason for not list one of them as SOA

the salve don't need the SOA because it's typically configured to use 
whatever server as master which allows zone transfers, frankly you can 
even chain slaves pulling zones from other slaves



I've previously asked Cricket Lou and Matt Larson, via Mr-DNS, if this
type of configuration (having an Master Name server not listed in the NS
records) is a problem and they indicated that it's not 100% ideal, but
it will not cause any problems as long as the listed NS servers are
accessible and used for delegation from the parent.  I.e. if your MNAME
server is behind a firewall that will only allow the slave NS servers to
communicate with it.

What was your intent in pointing that out?  That has nothing to do with
my original question.


that it's in general a good idea to use validation services and follow them


Further, I don't see any response to my question, mixing recursive and
authoritative resolvers in a SOHO scenario that is not internet accessible


the answer is: we are doing that for more than 10 years now



signature.asc
Description: OpenPGP digital signature
___
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

Re: separation of authoritative and recursive functions on internal networks

[Chris Buxton]

> On Jan 29, 2016, at 3:58 PM, Darcy Kevin (FCA)  
> wrote:
> 
> Data obtained from the recursive function will never outrank authoritative 
> data of a master or a slave.

Kevin,

That's true, but authoritative servers also sometimes serve up referrals, 
sometimes including glue records. This data is not authoritative, and I have 
seen it outranked by cached data. That can lead to odd failures, especially if 
the querier is denied access to the cache.

Regards,
Chris
___
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

Re: separation of authoritative and recursive functions on internal networks

[Mark Andrews]

In message <23f8b4f8-b0ea-436d-a700-87ac63248...@nau.edu>, Mathew Ian Eis 
writes:
> 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?

Yes.

> 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?

Correct.  You don't want the listed servers for the zone returning
data that is learnt via iterative/recursive lookups and the best
way to do that is to not have those servers recurse.

> Thanks in advance,
>
> Mathew Eis
> Northern Arizona University
> Information Technology Services
> mathew@nau.edu
> (928) 523-2960
>
>
>
>
>
>
>
>
> -Original Message-
> From:  on behalf of Mark Andrews
> 
> Date: Monday, August 10, 2015 at 11:12 AM
> To: Gary Carr 
> Cc: "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

-- 
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

Re: separation of authoritative and recursive functions on internal networks

[Mathew Ian Eis]

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:  on behalf of Mark Andrews 

Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr 
Cc: "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

RE: separation of authoritative and recursive functions on internal networks

[Darcy Kevin (FCA)]

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:  on behalf of Mark Andrews 

Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr 
Cc: "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

Re: separation of authoritative and recursive functions on internal networks

[Lawrence K. Chen, P.Eng.]

On 2015-08-10 13:12, Mark Andrews wrote:

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


Though it didn't work out the one time we had an extended link blockage (due 
to a full log volume - no log no pass)  At first local resolution continued 
working, until all the recursion slots (10,000) filled up on my (4) recursive 
servers, which are authoritative slave for local domain...had them stop 
answer anything.


Otherwise, its normally how we get local changes out quickly despite usually 
have a 1 day TTL.  Though when its a domain that we host that they want to 
see a quick local changewe sometimes do nasty cache flushes to make that 
change appear.  I have a script that takes care of thatwhich goes through 
all the servers without delays (I've debated on which is better, or if it 
doesn't matter.)  I've played around with flushname/flushtree, but they don't 
seem always work


So, I'm considering trying to separate things again.

--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) --  SafeZone Ally

___
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

Re: separation of authoritative and recursive functions on internal networks

[John Miller]

On Wed, Aug 5, 2015 at 10:18 AM, Gary Carr garycarr...@gmail.com wrote:

 Overall, is breaking this function out - internally - really worth it?


I can offer a personal testimonial on the management aspects of this:

A couple of years back, we made the switch from combined
authoritative/recursive servers to recursive-only and
authoritative-only systems.  The reasoning was more a logistics thing
than anything else: we wanted to host our authoritative records both
locally and with a cloud service, and moving the recursive portion was
easy to do.  We also weren't sure which daemons we wanted to use for
each side of things - PowerDNS recursor?  BIND?  unbound?  PowerDNS
authoritative?  NSD? - so separating the two functions gave us
flexibility in that arena.  It also meant we didn't have to worry
about views.  We treated the separation of authoritative and recursive
as gospel.

For recursive service, we initially ran three pdns-recursor instances
and two BIND instances, most behind a hardware load balancer.  For
authoritative service, we kept our records in Amazon Route 53, syncing
with four internal NSs: one hidden master and three slaves.  This let
us override records locally as needed and meant that we didn't have to
follow delegation from the root NSs (important - you're not relying on
100% border uptime for your internal network).

We've since moved our recursive stuff to BIND (for RPZ), and have
added a couple of additional internal authoritative servers, so we're
at 10+ DNS servers locally.  We're starting to become too complicated!
 Separating authoritative and recursive functions certainly makes it
easier to do maintenance and change daemons as necessary, but it's
added a layer of complexity that you might not want.

Something interesting we did is that our recursive servers don't
depend exclusively on our local authoritative servers.  In a pinch
(last master in the stub zone), they'll go out to our cloud DNS
servers and pull/follow delegation from there.  So the dependence of
recursive on authoritative, due to separation, isn't nearly as great.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
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

Re: separation of authoritative and recursive functions on internal networks

[Mark Andrews]

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

RE: separation of authoritative and recursive functions on internal networks

[Darcy Kevin (FCA)]

Separate authoritative and recursive functions is really a simplistic 
approach to a complex challenge. I think a better approach is to make both the 
published-authoritative function and the recursive-resolution functions robust 
enough *in*and*of*themselves* so that there is no value to an attacker taking 
down a single node or instance for either function. At that point, it doesn't 
matter whether you mix published-authoritative with recursive, or not.

So how do you make the published-authoritative function robust? The main way is 
to publish a sufficient number of NS records, and potentially some or all of 
those are Anycast'ed (and/or potentially hardware-load-balanced) to even more 
nodes. (Don't go overboard on your NS records, however, since this can lead to 
TCP retries). Similarly, you can use Anycast and/or hardware-load-balancing to 
make the recursive-resolver function robust, and doing so has the added benefit 
of simplifying stub-resolver configuration throughout your enterprise. Another 
thing you can do is implement stealth slaves for your critical zones (which, 
by the way, doesn't violate the spirit of separating the functions, since the 
motivation for that advice pertains to *published* authoritative service, and, 
by definition, stealth slaves aren't published). Stealth slaves are more 
resistant to DoS (since they answer from data which is local) and have no cache 
to poison. There are (expensive) hardware approaches to mitigating DoS, as well.

As another poster mentioned, the physical security of your DNS instances - 
whether they be authoritative or recursive or both - is important, as is the 
OS-level security, controlling access, keeping up on patches, watching the 
logs. All of the usual security precautions apply to DNS as apply to *any* 
infrastructure subsystem.

As for Internet-facing DNS instances, even there, I think hardware-level 
separation between published-authoritative and recursive, is a little 
overblown. If you have a hardened platform, keep up on patches, have 
centralized configuration control, people who know what they're doing, multiple 
levels of redundancy for each function, ingress filtering, etc. then view-level 
separation is sufficient.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Gary Carr
Sent: Wednesday, August 05, 2015 10:19 AM
To: bind-users@lists.isc.org
Subject: separation of authoritative and recursive functions on internal 
networks

Hello,

I understand the importance of separating authoritative and recursive functions 
on public facing systems. How crucial is it on internal systems?

My clients today resolve against internal servers that do recursion and also 
hold authoritative secondary copies of important internal zones. I did see on 
the ISC KB that this is an acceptable configuration 'having determined that the 
benefit outweighs any risks associated with this policy.

The primary benefit as I understand it, is that in removing the authoritative 
function from the recursive systems and isolating it on separate hardware (with 
an ACL permitting only the recursive servers to use them), I decrease the 
attack surface. The recursive servers are now isolated from being vulunerable 
to attacks against the authoritative code base.

In my environment, the recursive function is important, but not nearly as 
important as the authoritative resolution of internal namespaces.
Has this separation of function improved my security posture in that area? If 
we assume the internal environment is hostile, an attacker now simply has to 
launch their authoritative-busting code against the authoritative servers 
rather than the recursive servers, forging the source as the recursive servers? 
The end result is the same in either design - an outage for critical internal 
functionality.

What are the downsides? Is it a stretch to say that this design might actually 
introduce security concerns? For example, if the authoritative function is 
moved, and the clients are left pointing at na now recursive-only server- that 
recursive server is now theoretically vulnerable to cache poisoned records for 
those critical internal namespaces, where as previously that was impossible 
because it was answering them authoritatively?

Does this design potentially weaken operational stability? By breaking out the 
authoritative functions on to unique hardware, we've now introduced a second 
place in the service delivery chain where a failure will be catastrophic to 
business function?

Overall, is breaking this function out - internally - really worth it?

Thoughts and comments appreciated

Cheers!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list