Bug 71185 - bind-9.2.1-0.70.2 fails to do zone transfers
bind-9.2.1-0.70.2 fails to do zone transfers
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bind (Show other bugs)
7.2
i386 Linux
high Severity high
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-09 14:06 EDT by Daniel Senie
Modified: 2005-10-31 17:00 EST (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Daniel Senie 2002-08-09 14:06:19 EDT
Description of Problem:

RedHat Network has bind-9.2.1-0.70.2 in place to update earlier versions to fix 
a resolver problem. However, in updating a slave name server to this version, 
zone transfers now fail quickly with "refresh: failure trying master <server 
info>: time out".

This was a working, functional secondary name server for many hundreds of 
zones. We're now trying to figure out how to get back to Bind-8 so that we can 
return this server to functional service.

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

bind-9.2.1-0.70.2

How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:
Comment 1 Daniel Senie 2002-08-09 14:12:54 EDT
Additional notes:

From the same server where BIND claims AXFRs are timing out, I am able to do:

dig @masterserver zonename axfr

and get a nice, complete zone transfer to my screen.

Clearly, the master server is having no trouble serving up the zone transfers. 
The problem appears confined to the slave server.
Comment 2 Daniel Senie 2002-09-22 11:20:08 EDT
Another update on this issue. Since Bind-9 uses separate configuration items 
for transfer sorce and notify source, those items affected the operation of 
the servers in question.

This points out the folly of using a new release of a software product as 
an "errata" fix, without substantial documentation or warning. Errata should 
NOT break running systems.

Going from a bind-8 to a bind-9 to fix a bug may well have been the shortest 
path, but may well have cost many customers a lot of money figuring out and 
fixing systems which became inoperative. It's also possible this upgrade 
opened customers up to new vulnerabilities, as BIND-9 uses encryption 
libraries which have been the subject of errata.
Comment 3 Daniel Walsh 2003-01-06 13:53:02 EST
This was an upgrade issue, that should have been documented better.

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