Dangers of using nsupdate non-interactively

Chris Thompson cet1 at hermes.cam.ac.uk
Mon Apr 2 23:57:40 UTC 2007


We use nsupdate to update our zones, with the input to it
being prepared by procedures too elaborate to go into here. :-)

I've been caught out by the following "feature". The input
looked something this:

  server [master-ns]
  zone   [zonename]
  prereq yxrrset [zonename] 86400 IN SOA [mname] [rname] [old-serial] ... 
  update delete  <lots of RRs>
  update add     <lots of RRs>
  update add     [zonename] 86400 IN SOA [mname] [rname] [new-serial] ...
  send

Well, being experts you'll immediately see what is wrong with that.
RRs in prereq's are not allowed to have TTLs specified. (Unlike in
"update delete" where they can be specified but are ignored.)

So what did nsupdate do? It wrote a warning message to stdout, ignored
the prereq, went ahead and did the update apart from that, and gave an
exit code of zero (which meant that we never saw the warning message
in the ordinary course of events). Of course, the prereq was meant to
be a safety check, so we were not surprised it was never failing ... :-(

I have corrected the scripts that generate the nsupdate input, of course.
But it would be nice if nsupdate behaved better. Maybe a "stop immediately
(with a non-zero exit code) on any syntax error" option is needed?

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



More information about the bind-users mailing list