Bug 132113 - Wildcard entry broke when bind is upgrade to 9.2.4
Wildcard entry broke when bind is upgrade to 9.2.4
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: bind (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-08 18:17 EDT by Need Real Name
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-08 19:21:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
named.conf (1.29 KB, text/plain)
2004-09-08 19:19 EDT, Jason Vas Dias
no flags Details
root.db (169 bytes, text/plain)
2004-09-08 19:20 EDT, Jason Vas Dias
no flags Details

  None (edit)
Description Need Real Name 2004-09-08 18:17:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

Description of problem:
The following wildcard of entry works fine with bind-9.2.2-21:

*. 43200 IN A 192.168.1.50

This entry is needed for NetReg (available from
http://www.netreg.org/) to work correctly.  But 9.2.4-EL3_10:10
returns NXDOMAIN when the expected result that the wildcard entry will
return 192.168.1.50


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

How reproducible:
Always

Steps to Reproduce:
1.Install standard RHEL AS 3.0
2.Put in named.conf: zone "." in { type master; file "db.root"; }
3.Put in db.root a proper SOA and *. 43200 IN A 192.168.1.50
4.Start named
5.Run nslookup - 127.0.0.1 and look up google.com (192.168.1.50 will
be returned)
6.Run update -u and restart named
7.Run nslookup - 127.0.0.1 and look up google.com (NXDOMAIN will be
returned--the wildcard entry appears to be ignored)
    

Actual Results:  9.2.2-21 honors the wildcard entry
9.2.4-EL3_10:10 ignored the wildcard entry and returns NXDOMAIN

Expected Results:  Expected RHEL AS 3.0 updates to function similarly
such that the update still allows the NetReg to work as expected

Additional info:
Comment 1 Jason Vas Dias 2004-09-08 19:19:07 EDT
I have been unable to duplicate this problem, and was able
to get all names to resolve to the single address using
bind-9.2.4-10, with the same '*.' wildcard A record given above,
using the attached configuration files.
The named.conf is the same as the default named.conf from
the "caching-nameserver" package with the "root.db" root zone 
with the wildcard entry added.
Try the attached named.conf and root.db files and see if that works;
if not, check that named is running correctly - the 
"service named stop" and "service named stop" commands display 
"[ OK ]" and no errors, and the 'pgrep named' command displays 
a number (pid) .
If you still have problems, re-open this bug.


 
Comment 2 Jason Vas Dias 2004-09-08 19:19:50 EDT
Created attachment 103616 [details]
named.conf
Comment 3 Jason Vas Dias 2004-09-08 19:20:42 EDT
Created attachment 103617 [details]
root.db
Comment 4 Need Real Name 2004-09-09 14:01:16 EDT
Thanks for the quick responce.  I figured out the problem.  Consider
the following entries:

*.                           43200 IN A 192.168.1.50
download.windowsupdate.com.  43200 IN A 208.172.13.253

In v9.2.2, the wildcard takes presidence for EVERYTHING except the
where the specific *host* download.windowsupdate.com such that
google.com hits the wildcard

In v9.2.4, the wildcard takes presidence for everything except the
where the specific *domains* are listed (in this case, an entry under
the .com TLD is listed) such that google.com returns NXDOMAIN

The solution is to add wildcards for all domains listed such as:
*.                   43200   IN      A       192.168.1.50
*.com.               43200   IN      A       192.168.1.50
*.org.               43200   IN      A       192.168.1.50
*.edu.               43200   IN      A       192.168.1.50
*.windowsupdate.com. 43200   IN      A       192.168.1.50
*.someplace.org.     43200   IN      A       192.168.1.50
*.educause.edu.      43200   IN      A       192.168.1.50
download.windowsupdate.com. 43200 IN A       208.172.13.253
www.someplace.org.   43200   IN      A       66.151.148.171
www.educause.edu.    43200   IN      A       198.59.61.67

This returns the behavior of v9.2.2 when running v9.2.4
Comment 5 John Flanagan 2004-12-21 14:49:55 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-567.html

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