Bug 148036 - nsupdate from bind-utils-9.2.4-8_FC3 fails to update remote zone
nsupdate from bind-utils-9.2.4-8_FC3 fails to update remote zone
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-14 20:16 EST by Eduardo Kaftanski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-21 15:14:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
script that calls nsupdate (1.05 KB, text/plain)
2005-02-16 23:52 EST, Eduardo Kaftanski
no flags Details
named.conf portion for the updated zone (233 bytes, text/plain)
2005-02-16 23:55 EST, Eduardo Kaftanski
no flags Details

  None (edit)
Description Eduardo Kaftanski 2005-02-14 20:16:05 EST
Description of problem:
 If bind-utils-9.2.4-8_FC3  is installed, a script to update a remote 
zone running on another FC (2 or 3) fails. The remote named reports
'updating zone '<zone>/IN': update failed: update RR is outside zone 
(NOTZONE)'
  Reverting to bind-utils-9.2.3-13 (from FC2) fixes the problem.


Version-Release number of selected component (if applicable):
  9.2.4-8_FC3 

How reproducible:
  Always.

Steps to Reproduce:
1. Configure a zone in a remote server, running bind. Version does 
not seem to make a difference.
2. Configure that zone to allow updates from a remote bind. I use a 
key in the named.conf file.
3. Try to update the zone using nsupdate from a FC3 box having bind-
utils-9.2.4-8_FC3 installed.
  
Actual results:
  Update fails. Remote named reports 'NOTZONE' in syslog

Expected results:
  The zone should be updated

Additional info:
Comment 1 Jason Vas Dias 2005-02-16 10:41:12 EST
I can't reproduce this problem. 
Please supply details of the named configuration of the remote zone
you are trying to update, and the nsupdate command you use to update 
it - thank you.
Comment 2 Eduardo Kaftanski 2005-02-16 23:49:29 EST
I am attaching two files. pump.script is the script I call from
ip-up.local every time the local IP changes and named.conf is the
portion of the conf file the remote named has.
Comment 3 Eduardo Kaftanski 2005-02-16 23:52:29 EST
Created attachment 111150 [details]
script that calls nsupdate

pppd calls this via ip-up.local when IP changes.
Comment 4 Eduardo Kaftanski 2005-02-16 23:55:06 EST
Created attachment 111151 [details]
named.conf portion for the updated zone

Yes, the zone IS really nn.cl. :)
I can send the key for its update privately if you want to test, or
configre another zone with the same parameters.
Comment 5 Jason Vas Dias 2005-02-18 11:48:12 EST
I have now duplicated the problem.

The problem occurs because you do not fully qualify the name you are
updating:
ZONE="nn.cl"
HOSTNAME="e.nn.cl"

This must be changed to 
ZONE="nn.cl."
HOSTNAME="e.$ZONE"

Or if hostname is output of the hostname command, as in:
HOSTNAME="$(hostname | cut -d. -f1)"

This must be changed to:
HOSTNAME="$(hostname | cut -d. -f1).$ZONE"

Then these commands will work fine:
update delete $HOSTNAME
update add $HOSTNAME 60 A $IP
update add $HOSTNAME 60 MX 0 e.$ZONE


And you need to change:
update delete enriqueto
update add enriqueto 60 A $IP
update add enriqueto 60 MX 0 e.nn.cl.

To:
update delete enriqueto.$ZONE
update add enriqueto.$ZONE 60 A $IP
update add enriqueto.$ZONE 60 MX 0 e.$ZONE


It is possible that for some reason nsupdate is not honoring the
'zone nn.cl.' statement properly, while bind-9.2.3 does, or that
the restrictions on this have been tightened in BIND 9.2.4 - I will
check. 
Comment 6 Eduardo Kaftanski 2005-02-19 22:53:05 EST
You were right. I modified the script as told and upgraded to the FC3
bind and it now works perfectly. Look like it was not a bug, but
rather a 'feature' that got fixed. Thanks.

I think you can close it as a bug.
Comment 7 Jason Vas Dias 2005-02-21 15:14:01 EST
OK, thanks for your feedback - closing as 'NOTABUG'.

Note You need to log in before you can comment on or make changes to this bug.