separation of authoritative and recursive functions on internal networks

[Gary Carr]

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!

[Heiko Richter]

Hi!

It all depends on the overall design of your network.

Of course there is a chance of somone attacking your authoritative
nameservers. But that chance can be greatly reduced by other factors:

- Do you only have company-controlled workstations where "normal" users
have no root privileges or does your company employ a BYOD prolicy where
everyone can bring their notbook, including the malware that is on it?

- Do you have a security software that doesn't only look for viruses but
also for software capable of such atacks? Often distributed as "security
software" helping the administrator to do vital test... ;-)

- Do you have a network security policy like port security on your
switches that prohibits attaching private devices that one could use for
attacks?

- Do you have a firewall between the servers and the clients? If not, is
there at least a router between them, so a potential attacker can't
resort to the very basic attacks such as mac spoofing?

- Do you have enough redundancy that taking a server offline will not
affect your network?

- And of course the very basic question: Does your Bind run with the
latest security fixes or are there gaping holes in it because you prefer
the easy way of installing a pre-built package?

The list goes on and on; so you see keeping the authoritative
nameservice on seperate machines is just a tiny bit of a much larger
picture. Having dedicated servers for authoritative service will only
enhance your security if you can really make sure nobody but the
resolvers can reach them.

Otherwise in my oppinion it is just a wast of time and money to seperate
authoritative and resolving servers on an internal network. I would keep
the two services together and focus on making sure nobody is attacking
the servers you have.

Also if you really want to outsource somthing to another machine, I
would first look into using views to create a stealth-master-solution.
Seperate that hidden master into another network segment that is only
reachable from the "normal" nameservers. Also use DNSSec inline-signing
to let your master sign your zone on-the-fly to ensure authenticity of
the answers your resolvers/slaves send out.

The only thing you should definitely seperate from your internal
nameservers are the public ones facing the internet (if you have any).

Yours,
Heiko

[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 slave"s 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 slave"s 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-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of Gary Carr
Sent: Wednesday, August 05, 2015 10:19 AM
To: bind-...@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

bind-...@lists.isc.org

https://lists.isc.org/mailman/listinfo/bind-users

 

[Tony Finch]

Darcy Kevin (FCA) <kevin...@fcagroup.com> wrote:

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

However, you should consider failure scenarios, e.g. loss of external
connectivity, or loss of power.

In particular it is a very good idea for your on-site recursive servers to
be able to resolve your internal names without needing to iterate from the
root, because they can't do that when your external link is down.

An easy way to do this is to make your recursive servers authoritative for
your internal zones, and this has the added advantage of isolating them
from failures in other parts of your DNS infrastructure.

When you are bringing everything up after a power outage, it is very
helpful if your recursive servers can come up and start working without
anything else being up and working - avoids cyclic dependencies.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Irish Sea: Southwest 5 or 6, veering northwest 3 or 4. Slight, occasionally
moderate at first. Showers, fair later. Good.

[John Miller]

On Wed, Aug 5, 2015 at 10:18 AM, Gary Carr <garyc...@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
john...@brandeis.edu

[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

[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 change....we sometimes do nasty cache flushes to make that
change appear. I have a script that takes care of that....which 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

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

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

[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

[Mark Andrews]

In message <23F8B4F8-B0EA-436D...@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.

[Chris Buxton]

> On Jan 29, 2016, at 3:58 PM, Darcy Kevin (FCA) <kevin...@fcagroup.com> 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

[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.
}:-)

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

[Mark Andrews]

In message <56B7CDFB...@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.
> }:-)

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

[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

[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

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