Bug 419251 - resolver's gethostbyname fails if DNS reply is over 1024 bytes
resolver's gethostbyname fails if DNS reply is over 1024 bytes
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.9
All Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-11 00:34 EST by Doug Mitchell
Modified: 2007-12-12 04:43 EST (History)
0 users

See Also:
Fixed In Version: 2.3.4-2.39
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-12 04:43:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Mitchell 2007-12-11 00:34:02 EST
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 04:43:28 EST
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.

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