In message <1401739377.33916.yahoomail...@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: 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
