[EXTERNAL] Re: NOTAUTH on dynamic update followed by approved update

[Hellige, Charles D]

Tony,

Thank you for your detailed and thoughtfuly analysis. I think you are spot-on. I'm looking into the app that is sending those updates. And wahoo, I won a prize! That's awesome.

-----Original Message-----
From: Tony Finch <fanf at isc.org> 
Sent: Monday, March 14, 2022 4:23 PM
To: Hellige, Charles D <Charles.Hellige at charter.com>
Cc: bind-users at lists.isc.org
Subject: [EXTERNAL] Re: NOTAUTH on dynamic update followed by approved update

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.

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.