nameserver A record hijacking.

[Kevin Darcy]

Jim Reid wrote:

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

Not to nitpick, but the OP specifically asked about how to protect
*multiple* A records ("... or any other static record I would really like
to keep"). Maintaining big long lists of update-policy goop would be a
nightmare.

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

Okay, then, how are those protected records supposed to be maintained if
you've denied *all* Dynamic Updates to them? As we've pointed out here
many times, it's not safe to mix manual edits and Dynamic Updates in the
same zone. Yes, the OP may have asked (paraphrased) "how do I prevent
Dynamic Updates to specific records", but frankly I think that question
was a little naive. The _pertinent_ question is "how do I exercise
fine-grained control over my resource records so that only 'trusted' keys
can update certain critical records?". I addressed the latter question.

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

Yeah, and if we let those ignorant cavemen use fire, who knows what
mischief they might get into?!?! Given many millenia, they might invent
computers, and then they might even want to run nameservers on those
computers. We can't allow that! Technology and progress just causes
trouble!

If I was paternalistic in answering the question that the OP should have
asked instead of the question that they did ask, I think you're being at
least as paternalistic by arguing against powerful Dynamic Update controls
on the basis that they could be misused or abused. Give people the tools
and as much instruction as possible so that they use those tools properly.
If some of them misuse or abuse the tools, then so be it.

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

Yes, as I said, if you're already lucky enough to have a subdomain-based
naming convention like that in force, then update-policy works fine. But
what if you have "important" records throughout the zone that only follow
naming conventions in their first label (e.g. the ever-popular
"ns1.example.com", "ns2.example.com" convention)? Then update-policy's
poor matching syntax doesn't help you avoid a maintenance nightmare. That
was the gist of my point.


- Kevin