Date: Tue, 2 Mar 1999 04:17:44 -0700 From: Michael Fuhr <mfuhr@dimensional.com> To: Bill Fenner <fenner@parc.xerox.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/10344: Core dump in gethostbyaddr for 199.93.70.2 Message-ID: <19990302041744.B29139@flatland.dimensional.com> In-Reply-To: <199903020800.AAA50261@freefall.freebsd.org>; from Bill Fenner on Tue, Mar 02, 1999 at 12:00:02AM -0800 References: <199903020800.AAA50261@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 02, 1999 at 12:00:02AM -0800, Bill Fenner wrote:
> Aha! I must be using a name server that's truncating - I only got
> 14 answers. If I set my name server to monster.nlc.net.au, I get
> lots of answers and a core dump. tcpdump shows that the clean 14
> answers come in a UDP packet and then it opens a TCP connection.
> "dig" says that the TCP response is malformed. Since "dig" complains
> about a malformed packet instead of dumping core, that might be a
> better place to start to try to figure out what's going on. (The
> header claims to contain 810 answers but dig only prints 272 before
> printing an error. The 24k of data on the wire contains much more
> than dig displays, but I don't have a good way of telling whether
> or not it's really malformed.)
I wrote a Perl script using Net::DNS to query the zone's primary
nameserver (apparently shields.burlee.com, 199.93.70.3) and got the
following:
;; ANSWER SECTION (810 records)
Deep recursion on subroutine "Net::DNS::Packet::dn_expand"
at /usr/local/lib/perl5/site_perl/5.005/Net/DNS/Packet.pm line 614.
Out of memory!
After adding a check for loops in the DNS name compression mechanism,
I discovered that the first record in the answer section has a loop:
Field
Offset : Data
Header
0000 : f9a1 8580 0001 032a 0000 0000
Question Section - QNAME (2.70.93.199.in-addr.arpa)
000c : 0132 0237 3002 3933 0331 3939 0769 6e2d 6164 6472 0461 7270 6100
Question Section - QTYPE (PTR)
0026 : 000c
Question Section - QCLASS (IN)
0028 : 0001
Answer Section - NAME (pointer to 2.70.93.199.in-addr.arpa)
002a : c00c
Answer Section - TYPE (PTR)
002c : 000c
Answer Section - CLASS (IN)
002e : 0001
Answer Section - TTL (3600)
0030 : 0000 0e10
Answer Section - RDLENGTH (2)
0034 : 0002
Answer Section - RDATA (PTRDNAME - pointer to itself)
0036 : c036
> Another odd thing is that the connection ends with a TCP reset; the
> last few segments are really weird. Instead of the >FIN, <FIN/ACK, >ACK,
> it's >FIN, <FIN/ACK, >ACK, <ACK, >ACK, <RST. This could be what's
> causing the truncation, since a RST flushes any queued data.
With Net::DNS I got >FIN, <ACK, <FIN/ACK, >ACK (no RST).
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990302041744.B29139>