Problems updating apex NS rrset

[Mark Andrews]

> 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

	The protocol won't allow this.  At no time during the processing
	of a update is the NS RRset for the zone allowed to be empty.
 
>   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.

   7.13. Zone cut management presents some obscure corner cases to the 
   add and delete operations in the Update Section.  It is possible to
   delete an NS RR as long as it is not the last NS RR at the root of a
   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
   a zone are unaffected.  If deleting RRsets, it is not possible to   
   delete either SOA or NS RRsets at the top of a zone.  An attempt to
   add an SOA will be treated as a replace operation if an SOA already
   exists, or as a no-op if the SOA would be new.

 
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org