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 ape
> x 
> > 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 the
> n
> > 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.

	I forgot to add that you can't look forward in the UPDATE section
	to see if there is a addition as they need to be processed in
	order.

   3.4.2 - Update

   The Update Section is parsed into RRs and these RRs are processed in
   order.

> 
>  
> > -- 
> > 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
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org