stub zones

[Mark Andrews]

In message <1401739377.33916.YahooMailNeo at web163502.mail.gq1.yahoo.com>, Nex6|B
ill writes:
>
> recently, a question came up about "stub" zones came up and what they are
> and are they part of the DNS standards or are they a good idea. i said,
> they are evil and should not be used if you can avoid it.  they way I
> understand them is the are when you create local zones for zones you are
> NOT authoritative for. and; the records in the stub zone do not update
> when the authoritative NS does.
>
>
> correct? thoughts?
>
>
> -Nex6

Firstly stub zones are NOT part of any standard.  They are a BIND
invention.

Stub zones are a way to introduce a short cut delegation.  Say you
are using 10.0.0.0/8 internally.  There is not delegation from the
Internet to the internal servers for 10.in-addr.arpa.

Now you could slave 10.in-addr.arpa on every internal server.

Alternatively you could create a stub zone for 10.in-addr.arpa on
every internal server which effectively provides a private delegation
overriding that the server would have learnt from the Internet.

The third alternative which I really discourage is to use forwarders
but that introduces even more problems.  They were designed to get
around firewalls and sometimes override a delegation. They were NOT
designed to introduce delegations but some people try to do that with
them.

I personally think using slaves for this is better but the does
require that acls be relaxed enough to permit zone transfers.  Also
if you stuff up serial number updates it is harder to fix as there
are more slaves involved.  It also lengthens some of the DNSSEC
timings involved with key maintenance as you often don't have a
full list of the slaves so you can't check that the zone has
transfered to everyone of them.  Zone transfers also rely on the
SOA timers rather than NOTIFY to be triggered unless you update the
also notify list when you add a new recursive server (or update the
NS list but doesn't scale).  This is usually not a issue for the
apex of the reverse zone but can be a issue in the forward namespace.

Slave zones also work with any RFC compliant server so you can mix
and match implementations.

Stub zones can also be used as a alternative to a hint zone.  Changes
to the root NS RRset and the root server addresses will be tracked.

Back when data leaked between zones stubs provided a method to keep
the delegation data up to date.  This is no longer supported as it
can lead to stale data in slaves which isn't in any master due to
timing issues.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org