---
title: "nsupdate issues in EOL versions of BIND"
slug: "aa-01220"
description: "A minor bug fix in some EOL versions of BIND introduced a regression that made the nsupdate utility fail to resolve."
updated: 2019-06-06T13:44:54Z
published: 2019-06-06T13:44:54Z
canonical: "kb.isc.org/aa-01220"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

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

BIND 9.9.x and 9.10.x are EOL As of July 2018, the BIND 9 versions described in this article are End of Life. Please visit [https://www.isc.org/downloads/](https://www.isc.org/downloads/) to download a currently supported version, or contact us at [https://www.isc.org/contact/](https://www.isc.org/contact/) with questions.

                         

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](https://kb.isc.org/docs/aa-01216))
- Specify a "server" argument in **nsupdate** input
- Run **nsupdate** on the SOA MNAME host in local-host only mode using the -l flag