Bug 71185 - bind-9.2.1-0.70.2 fails to do zone transfers
Summary: bind-9.2.1-0.70.2 fails to do zone transfers
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bind   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-09 18:06 UTC by Daniel Senie
Modified: 2005-10-31 22:00 UTC (History)
0 users

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

Attachments (Terms of Use)

Description Daniel Senie 2002-08-09 18:06:19 UTC
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):


How Reproducible:

Steps to Reproduce:

Actual Results:

Expected Results:

Additional Information:

Comment 1 Daniel Senie 2002-08-09 18:12:54 UTC
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 15:20:08 UTC
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 18:53:02 UTC
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.