Restrict Dynamic Updates to a Portion of a Zone

[Cricket Liu]

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

I'd recommend taking a look at the BIND 9 docs.  There's a
description in the docs already of the new access control
mechanism, which relies on TSIG keys and looks very
flexible.

cricket

Acme Byte & Wire
cricket at acmebw.com
www.acmebw.com

Attend the next Internet Software Consortium/Acme Byte & Wire
DNS and BIND class!  See www.acmebw.com/training.htm for
the schedule and to register for upcoming classes.