Bug 132113 - Wildcard entry broke when bind is upgrade to 9.2.4
Summary: Wildcard entry broke when bind is upgrade to 9.2.4
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: bind
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-08 22:17 UTC by Need Real Name
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-08 23:21:30 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:567 0 normal SHIPPED_LIVE Updated bind packages 2004-12-21 05:00:00 UTC

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



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