nameserver A record hijacking.

[Jim Reid]

>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Greg> Hi, I would like to know how to prevent nsupdate or any DDNS
    Greg> tool from being able to modify an A record, which just
    Greg> happens to be the nameserver A record, or any other static A
    Greg> record I would really really like to keep.
    >>  Take a look at update-policy{} in BIND9.2.

    Kevin> update-policy{} is fine if you are fortunate enough to
    Kevin> already have a naming convention in force which allows you
    Kevin> to use a wildcard for all of your "restricted" names but
    Kevin> if you don't, then you're stuck with either "self" (which
    Kevin> is a key-management nightmare) or you have to do a lot of
    Kevin> renaming

This is irrelevant and you miss the point. The OP asked how to prevent
an individual resource record from being updated. update-policy{} does
exactly that. For example:

	update-policy {
		deny * name foo.example.com A;
	};

ie: all clients are not permitted to update any A records for
foo.example.com.

The OP asked "how to prevent nsupdate or any DDNS tool from being able
to modify an A record". I answered that question. He didn't ask about
fine-grained controls for *allowing* dynamic updates.

    Kevin> As I've said before, what update-policy{} badly needs IMO is
    Kevin> a rich regular-expression syntax instead of just simplistic
    Kevin> wildcarding. 

I disagree. Few people already understand update-policy{}. Adding more
complexity to it will not improve that situation. If anything it will
make things worse because it will give more opportunities for people
to screw up. eg By causing someone to unintentionally set up less
restrictive controls on update than they realised. The existing
features of update-policy{} probably do what you want to achieve
without exhaustive lists of TSIG keys or RR names. Try looking at they
problem you want to solve from a different perspective. For example if
you only want a few boxes to update an arbitrary number of SRV records
or something like that, try:

	update-policy {
		allow trustme subdomain _sites.example.com SRV;
	};

ie Only clients using the TSIG key trustme can update SRV records that
are a subdomain of _sites.example.com.