Restrict Dynamic Updates to a Portion of a Zone

[Kevin Darcy]

docbrown at mailexcite.com wrote:

> In article <MMrI4.42$lD5.1555 at burlma1-snr2>,
>   Barry Margolin <barmar at genuity.net> wrote:
> > In article <8cstu4$5qd$1 at nnrp1.deja.com>,  <docbrown at mailexcite.com>
> wrote:
> > >In article <cYrH4.78$Nc4.2380 at burlma1-snr2>,
> > >  Barry Margolin <barmar at genuity.net> wrote:
> > >> In article <8clets$d9u$1 at nnrp1.deja.com>,
> <docbrown at mailexcite.com>
> > >wrote:
> > >> >Is there anyway using Bind 8.2.2p5 to restrict what parts of a
> give
> > >zone
> > >> > can be updated dynamically?
> > >> >
> > >> >For example, say I have a zone, testzone.com with hosts A, B, C,
> D.
> > >Can
> > >> >I say let the hosts and IP address for C and D be updated
> dynamically
> > >> >while never dynamically change A and B?
> > >>
> > >> You could delegate A and B into zones of their own:
> > >>
> > >> zone "testzone.com" {
> > >>   ...
> > >>   allow-update { ... };
> > >> };
> > >>
> > >> zone "a.testzone.com" {
> > >>   ...
> > >> };
> > >>
> > >> zone "b.testzone.com" {
> > >>   ...
> > >> };
> > >>
> > >
> > >A good idea, but the NS records for zone a.testzone.com or
> > >b.testzone.com are store in testzone.com and those NS records could
> be
> > >updated/changed.
> >
> > They'll be ignored, because the more specific records in the
> subdomains
> > take precedence.
> >
> > --
> > Barry Margolin, barmar at genuity.net
>
> You're right that works, but for a semi-large number of hosts that
> shouldn't be dynamicly updated this can become a pain to administer.
>
> Does anybody know of a way to create one's own resource type?  Say I
> have an 'A' type which is the zone default, an 'AD' type which will
> always be able to be dynamicaly updated (overiding the zone default) and
> an 'AN' tpe which will never be updated?  Bind would just return the IP
> address for these as a normal 'A' type and only pay attention to the D/N
> when updates are requested?  Just a thought.

As a protocol enhancement proposal, you could float the idea on the
"namedroppers" mailing list, but a word of warning: it's likely to be shot
down in short order. New record types are generally frowned upon unless
there is a very compelling reason for their addition, since new types,
especially when they effectively redefine or overload the meaning of
existing types -- as your proposed types do -- tend to break compatibility
with older software and the software upgrade speed of the DNS community as
a whole tends to be measured in the many years, if not in decades.

Whether a given record is available to be dynamically updated would seem to
be more a matter of local policy than of protocol. After all, if the
updates can only be made to the master, then there's only 1 machine in the
world which really needs to make the decision of whether or allow or deny
the update. Why then propagate this local-policy information to everyone
else and their brother in the form of a differentiated record type? Maybe
what is called for here is a master-file directive ($UPDATEABLE,
$NONUPDATEABLE?), or - my pet idea -- just have BIND refuse dynamic updates
of anything $INCLUDE'd into the master file, which allows for a fairly
clean demarcation of what is updateable and what isn't.


- Kevin