separation of authoritative and recursive functions on internal networks

[Mark Andrews]

In message <56B7CDFB.5070407 at 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 at 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: marka at isc.org