NOTAUTH on dynamic update followed by approved update

[Tony Finch]

Hellige, Charles D <Charles.Hellige at charter.com> wrote:

> We have been using nsupdate for some time without issue. We recently
> started seeing NOTAUTH failures in the named logs followed by successful
> adding/deleting messages. The records are getting created but there are
> times when we see several (NOTAUTH) errors before we finally get a
> successful message.

My wild guess is that someone is using a DNS UPDATE client that has a
noisy and blundering algorithm for working out which zone it is updating.

In a DNS UPDATE message, the first section (corresponding to the question
section in a normal DNS query) contains the name of the zone to be
updated. If the DNS server is not authoritative for that zone, it returns
a NOTAUTH error. And the zone name to be an exact match for the name of
the zone apex (its SOA record), no subdomains allowed.

> 11-Mar-2022 10:07:19.748 update: info: grn-mid: view GRN: updating zone 'ops.company.com/IN': update failed: not authoritative for update zone (NOTAUTH)
> 11-Mar-2022 10:07:19.821 update: info: grn-mid: view GRN: updating zone 'ops.company.com/IN': adding an RR at 'test-09.ops.company.com' A 1.1.1.9

These log messages tell me two (or maybe three) things: first, the NOTAUTH
error is provoked by an UPDATE request whose zone is a subdomain of the
correct zone. (The zone name in the log message is the closest match, not
the name from the request.) And second, the UPDATE was trying to add a
record that is not a direct subdomain of the zone apex, it's a
sub-sub-domain. (And third, the NOTAUTH log message is probably a
bug because it should state the zone name from the request not the closest
match in the server configuration.)

So it looks like the UPDATE client is searching for the correct zone in a
ham-fisted way, by taking the name of the record and stripping off a label
each time it gets a NOTAUTH response from the server.

By contrast, what `nsupdate` does is make a SOA query for the name of the
record it is tryng to update (or the first one, I guess, if there's more
than one). If the record is not at a zone apex then the negative response
will contain the SOA record for the correct zone in its AUTHORITY section.

(PS. you get the prize for my first message to this list with my new email address!)

-- 
Tony Finch  <fanf at isc.org>  (he/they)  Cambridge, England
Viking, North Utsire, South Utsire: Southerly or southeasterly 5 to 7.
Moderate or rough, becoming slight or moderate in South Utsire.
Occasional drizzle. Good, occasionally poor.