TechnitiumSoftware/DnsServer · error · ArgumentException

The Dynamic Updates option is invalid for {0} zones: {1}

Error message

The Dynamic Updates option is invalid for {0} zones: {1}

What it means

Thrown by the ForwarderZone.Update property setter when value is AuthZoneUpdate.AllowOnlyZoneNameServers (2) or AuthZoneUpdate.AllowZoneNameServersAndUseSpecifiedNetworkACL (4). Dynamic DNS updates (RFC 2136) gated to 'zone name servers' require an authoritative NS set, which a Conditional Forwarder lacks; the zone only forwards queries, it does not accept dynamic updates from NS peers. Valid update options for a forwarder zone are Deny(0), Allow(1), and UseSpecifiedNetworkACL(3). ArgumentException names 'Update'.

Source

Thrown at DnsServerCore/Dns/Zones/ForwarderZone.cs:363

                            break;

                        throw new ArgumentException("The Notify option is invalid for " + GetZoneTypeName() + " zones: " + value.ToString(), nameof(Notify));
                }

                base.Notify = value;
            }
        }

        public override AuthZoneUpdate Update
        {
            get { return base.Update; }
            set
            {
                switch (value)
                {
                    case AuthZoneUpdate.AllowOnlyZoneNameServers:
                    case AuthZoneUpdate.AllowZoneNameServersAndUseSpecifiedNetworkACL:
                        throw new ArgumentException("The Dynamic Updates option is invalid for " + GetZoneTypeName() + " zones: " + value.ToString(), nameof(Update));
                }

                base.Update = value;
            }
        }

        #endregion
    }
}

View on GitHub (pinned to d0484b6c1e)

Solutions

  1. For a ForwarderZone use Update = Deny, Allow, or UseSpecifiedNetworkACL.
  2. If you genuinely need NS-authenticated dynamic updates, use a primary zone instead of a conditional forwarder.
  3. Filter the Update enum options by zone type in your settings surface.

Example fix

// before
zone.Update = AuthZoneUpdate.AllowOnlyZoneNameServers;

// after
zone.Update = AuthZoneUpdate.UseSpecifiedNetworkACL;
Defensive patterns

Strategy: type-guard

Validate before calling

var valid = new[] { AuthZoneUpdate.Deny, AuthZoneUpdate.Allow, AuthZoneUpdate.UseSpecifiedNetworkACL };
if (!valid.Contains(value)) throw new ArgumentException($"Update {value} not valid for forwarder zone.");
zone.Update = value;

Type guard

static bool IsValidForwarderUpdate(AuthZoneUpdate v) => v == AuthZoneUpdate.Deny || v == AuthZoneUpdate.Allow || v == AuthZoneUpdate.UseSpecifiedNetworkACL;

Try / catch

try { zone.Update = value; }
catch (ArgumentException) { zone.Update = AuthZoneUpdate.UseSpecifiedNetworkACL; }

Prevention

When it happens

Trigger: Assigning zone.Update = AuthZoneUpdate.AllowOnlyZoneNameServers (or ...AndUseSpecifiedNetworkACL) on a ForwarderZone, typically via the dynamic-updates setting in the zone API or an import.

Common situations: Enabling RFC 2136 dynamic updates with a name-server ACL on a forwarder by mistake; copying primary-zone update settings; provisioning scripts that set the same Update enum for every zone.

Related errors


AI-assisted analysis of TechnitiumSoftware/DnsServer@d0484b6c1e (2026-08-13). Data as JSON: /api/errors/ea72efada2a2b06e. Report an issue: GitHub.