Problems updating apex NS rrset

[Chris Thompson]

For the last several months we've been updating all zones mastered locally
using dynamic update, generating input to nsupdate by comparing the old and
new versions of the zone. The general style of the updates is

   prereq yxrrset [name] [type] [data]      *#rrs in old RRset
OR prereq nxrrset [name] [type]
   update delete  [name] [type]   
   update add     [name] [type] [data]      *#rrs in new RRset, maybe 0

i.e. throw away the old RRset and rebuild it from scratch.

A problem has turned up in connection with updating the NS RRset at the apex 
of a zone. It seems that BIND (this is 9.2.5) won't let you remove all the 
NS records at the apex, but rather than giving an error it just ignores the 
request to update. In the case of

  update delete   [apex] NS

it leaves just one of the old NS records in place -- I haven't been able to
work out whether the survivor is chosen at random or not. 

This is wrong, wrong, WRONG. If BIND wants to enforce the (reasonable) 
constraint that there always be at least one NS record at the apex, it
should (1) check this only after the whole (indivisible) update has been
applied, not after intermediate stages - i.e. delete all NS records and then
add at least one again should be ok, and (2) if the constraint is violated it
should give an error response to the update, not quietly make the NS RRset
something other than was requested.

The current behaviour grossly violates the Principle of Minimum Surprise.
I've no doubt I can work around it, but why should I have to?

PS. I've looked at RFC 2136: I don't find any justification for this
behaviour of BIND there.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk