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
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
Depends On:
  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:
Last Closed: 2005-02-21 15:14:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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 
  Reverting to bind-utils-9.2.3-13 (from FC2) fixes the problem.

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

How reproducible:

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

This must be changed to 

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.

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
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.