Bug 165802 - resolver fails on truncated dns replies
resolver fails on truncated dns replies
Status: CLOSED DUPLICATE of bug 161181
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-12 09:18 EDT by Avi Kivity
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-21 12:42:13 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)

  None (edit)
Description Avi Kivity 2005-08-12 09:18:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko)

Description of problem:
if a reply from the nameserver is too big, causing the truncated bit to be 
set, the resolver fails. dig works. 
 
[avi@firebolt ~]$ ping en.wikipedia.org 
ping: unknown host en.wikipedia.org 
 
[avi@firebolt ~]$ dig en.wikipedia.org 
;; Truncated, retrying in TCP mode. 
 
; <<>> DiG 9.3.1 <<>> en.wikipedia.org 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30766 
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 13, ADDITIONAL: 0 
 
;; QUESTION SECTION: 
;en.wikipedia.org.              IN      A 
 
;; ANSWER SECTION: 
en.wikipedia.org.       3536    IN      CNAME   rr.wikimedia.org. 
rr.wikimedia.org.       536     IN      CNAME   rr.pmtpa.wikimedia.org. 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.247 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.248 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.202 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.203 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.204 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.205 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.206 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.210 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.213 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.214 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.235 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.236 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.245 
rr.pmtpa.wikimedia.org. 3537    IN      A       207.142.131.246 
 
;; AUTHORITY SECTION: 
.                       363058  IN      NS      H.ROOT-SERVERS.NET. 
.                       363058  IN      NS      I.ROOT-SERVERS.NET. 
.                       363058  IN      NS      J.ROOT-SERVERS.NET. 
.                       363058  IN      NS      K.ROOT-SERVERS.NET. 
.                       363058  IN      NS      L.ROOT-SERVERS.NET. 
.                       363058  IN      NS      M.ROOT-SERVERS.NET. 
.                       363058  IN      NS      A.ROOT-SERVERS.NET. 
.                       363058  IN      NS      B.ROOT-SERVERS.NET. 
.                       363058  IN      NS      C.ROOT-SERVERS.NET. 
.                       363058  IN      NS      D.ROOT-SERVERS.NET. 
.                       363058  IN      NS      E.ROOT-SERVERS.NET. 
.                       363058  IN      NS      F.ROOT-SERVERS.NET. 
.                       363058  IN      NS      G.ROOT-SERVERS.NET. 
 
;; Query time: 8 msec 
;; SERVER: 127.0.0.1#53(127.0.0.1) 
;; WHEN: Fri Aug 12 16:16:21 2005 
;; MSG SIZE  rcvd: 519 
 
note that dig notices the reply is truncated an retries using tcp. 

Version-Release number of selected component (if applicable):
glibc-2.3.5-10

How reproducible:
Always

Steps to Reproduce:
1. open http://en.wikipedia.org 
 
I also reproduced the problem by adding a dns name with many A records to my 
nameserver. 

Actual Results:  unknown host 

Expected Results:  page displayed  

Additional info:

marking as high priority since popular sites are likely to have many A 
records.
Comment 1 Jakub Jelinek 2005-08-12 11:43:42 EDT
Can't reproduce this.  Could this be a problem in your local nameserver?
Comment 2 Avi Kivity 2005-08-12 11:56:38 EDT
I saw it on two machines (both FC4 with local nameservers, one i386 and one 
x86-64) 
 
it's not 100% reproducible with wikipedia - the authority section is sometimes 
missing, which means the reply does not get truncated. it's easy to reproduce 
by adding an entry to a local domain with plenty of A records: 
[avi@firebolt ~]$ sudo cat /var/named/localhost.zone 
 
$TTL 86400 
@       IN      SOA     @  root.localhost ( 
                        1 ; serial 
                        28800 ; refresh 
                        7200 ; retry 
                        604800 ; expire 
                        86400 ; ttl 
                        ) 
 
 
@       IN      NS      localhost. 
 
 
@       IN      A       127.0.0.1 
 
beep IN A 1.2.3.4 
beep IN A 1.2.3.5 
 
[...many more...] 
 
beep IN A 1.2.3.6 
beep IN A 1.2.73.13 
beep IN A 1.2.73.14 
 
[avi@firebolt ~]$ ping beep.localhost 
ping: unknown host beep.localhost 
[avi@firebolt ~]$ dig beep.localhost 
;; Truncated, retrying in TCP mode. 
 
; <<>> DiG 9.3.1 <<>> beep.localhost 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28631 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 80, AUTHORITY: 1, ADDITIONAL: 1 
 
;; QUESTION SECTION: 
;beep.localhost.                        IN      A 
 
;; ANSWER SECTION: 
beep.localhost.         86400   IN      A       1.2.73.7 
beep.localhost.         86400   IN      A       1.2.73.8 
beep.localhost.         86400   IN      A       1.2.73.9 
beep.localhost.         86400   IN      A       1.2.73.10 
[... many more ...] 
 
again note the comment about truncation and tcp. 
 
I've verified this with ethereal as well. 
Comment 3 Avi Kivity 2005-08-12 13:12:50 EDT
another way to reproduce: 
 
  dig . ns; ping en.wikipedia.org 
 
this makes the nameserver (bind-9.3.1-8.FC4) return the extra authority 
section. 
Comment 4 Ulrich Drepper 2005-08-21 12:42:13 EDT

*** This bug has been marked as a duplicate of 161181 ***

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