question about reverse zones and nsupdate

[Darcy Kevin (FCA)]

Are you explicitly specifying the target zone using the “zone” keyword of nsupdate, or explicitly specifying the target server using the “server” keyword?

In the absence of either of those, then nsupdate is going to try to determine the containing zone, and the target server(s) for the zone, by issuing queries to whatever is configured as the local resolver. If this algorithm doesn’t return reasonable contents for the SOA.MNAME of the containing zone, you’ll try to UPDATE a server that’s not authoritative for the zone, and end up with that “NOTZONE” error.

I would start with everything explicitly specified – both “zone” and “server” – and if that works, then, if desired, troubleshoot where the lookup-based zone-and/or-server determination is falling down. You can mimic the algorithm by issuing a query for the name you’re trying to update, QTYPE=SOA. That should give you either a straight answer, if the name happens to own an SOA RR, or it should give you the SOA of the closest-enclosing-zone in the Authority Section (where it is used for negative caching purposes). Either way, the SOA that is returned is that of the zone you need to update, and whatever is contained in the SOA.MNAME is going to be the preferred target server for the update.

                                                                                                                                                                                    - Kevin

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of kevin martin
Sent: Wednesday, June 07, 2017 4:19 PM
To: bind-users at lists.isc.org
Subject: question about reverse zones and nsupdate

I have tried to setup a reverse zone as 10.10.in-addr.arpa and perform 'update add' commands sending addresses like 22.22.10.10.in-addr.arpa and 2.5.10.10.in-addr.arpa and, in all cases, the update fails with NOTZONE.  bind complains "update failed: update RR is outside zone (NOTZONE)".  Just how "tight" does the arpa zone need to be?  what would be IN zone in this case?  When I'm NOT using dynamic dns I have a zone file that is ORIGIN in-addr.arpa and just post manual entries that look like "22.22.10.10.in-addr.arpa. PTR host.myhosts.com<http://host.myhosts.com>" and reverse resolution works fine.


---


Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170607/07679557/attachment.html>