Bug 132113

Summary: Wildcard entry broke when bind is upgrade to 9.2.4
Product: Red Hat Enterprise Linux 3 Reporter: Need Real Name <bgallia>
Component: bindAssignee: Jason Vas Dias <jvdias>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-08 23:21:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
named.conf
none
root.db none

Description Need Real Name 2004-09-08 22:17:49 UTC
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 23:19:07 UTC
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 23:19:50 UTC
Created attachment 103616 [details]
named.conf

Comment 3 Jason Vas Dias 2004-09-08 23:20:42 UTC
Created attachment 103617 [details]
root.db

Comment 4 Need Real Name 2004-09-09 18:01:16 UTC
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 19:49:55 UTC
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