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 existed in BIND 9.9.6-P1 and 9.10.1-P1, but it was not considered important enough to stop the releases thereof. It was 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