nsupdate in BIND 9.9.6, 9.10.0 and 9.10.1 fail to resolve the SOA MNAME in some cases


A minor bugfix added to BIND 9.9.6, 9.8.8 and 9.10.0 introduced a regression that makes the nsupdate(8) utility fail to resolve (and thus fail to send updates to) the SOA MNAME host in some cases.  (The MNAME or master name is the first text value in a zone's SOA record; by default that is the host to which nsupdate will send updates for that zone.)

This occurs when all of these conditions exist

  1. SOA MNAME server name is in a different zone (not in the zone being updated)
  2. SOA MNAME server is not authoritative for that other zone
  3. SOA MNAME server refuses recursive queries from the nsupdate client

What happens: nsupdate queries the SOA MNAME server for its own name.  If it gets no answer or the answer is "REFUSED", nsupdate falls back to the server from which it obtained the SOA query response (this is typically the nameserver listed in resolv.conf(5).)

This regression still exists in BIND 9.9.6-P1 and 9.10.1-P1, but it was not considered important enough to stop the releases thereof.  It will be addressed in BIND 9.9.7, 9.10.2 and future versions.  BIND 9.8 is EOL and will not be fixed.

Workarounds are possible:

  • Continue using current versions of BIND, but revert to an older copy of nsupdate from BIND 9.9.5 or 9.8.7 as appropriate (nsupdate is not affected by CVE-2014-8500)
  • Specify a "server" argument in nsupdate input
  • Run nsupdate on the SOA MNAME host in local-host only mode using the -l flag
If none of the workarounds are adequate, the patches attached to this article (see below) can be applied against the BIND-9.9.6-P1 or 9.10.1-P1 source code.