Bug 419251

Summary: resolver's gethostbyname fails if DNS reply is over 1024 bytes
Product: Red Hat Enterprise Linux 3 Reporter: Doug Mitchell <redhat>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 3.9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.3.4-2.39 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-12 09:43:28 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:

Description Doug Mitchell 2007-12-11 05:34:02 UTC
Description of problem:
If the glibc resolver receives a DNS reply that exceeds 1024 bytes,
gethostbyname will return failure, even if the host actually exists.

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

How reproducible:
Query a DNS A record using gethostbyname which returns a large answer.  This is
usually caused by a large amount of A records (round-robin), a long CNAME chain,
or a large amount of additional NS records returned by the nameserver

  
Actual results:
Resolver says that host does not exist.


Expected results:
Resolver should match the output of host, dig, and nslookup, which say that the
hosts exists and return the proper IP address.


Additional info:
Packet size may have been limited way back in RH 7.2 to prevent buffer
overflows, but the may have broken some functionality.  Since "additional
nameserver" information is thrown away and gethosthostbyname only return address
info, this should be safe.

The problem was observed on a zone with a large number of authoritative name
servers that had very long FQDNs.  DNS request/response was over TCP due to
large size.

Thanks,
Doug

Comment 1 Jakub Jelinek 2007-12-12 09:43:28 UTC
RHEL3 is already in Maitanance phase and this isn't a security problem, nor
selected mission critical bug.  See https://www.redhat.com/security/updates/errata/
I believe we have fixed this problem in RHEL4 or RHEL5; if you can reproduce it
with later RHEL releases, please reopen.