Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!uflorida!mlb.semi.harris.com!algol.mlb.semi.harris.com!del
From: del@algol.mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: bind 4.8.3 : malformed response - worry ?
Message-ID: <1991Feb13.184821.24424@mlb.semi.harris.com>
Date: 13 Feb 91 18:48:21 GMT
References: <2302@tuvie.UUCP> <2303@tuvie.UUCP>
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 25
Nntp-Posting-Host: algol.mlb.semi.harris.com

In article <2303@tuvie.UUCP> chytil@vlsivie.tuwien.ac.at (Chytil Georg) writes:
>I'm running a slightly adapted bind 4.8.3 on an Apollo DN3500 Domain/OS 10.2 .
>
>Bind works just fine (maybe a bit slow, but this is probably due to the net), 
>but every other day it comes up with a burst (20 or so) of messages like
>
>Feb  8 08:29:44 vlsivie named[116]: Malformed response from 192.16.202.1
>Feb  8 08:30:30 vlsivie named[116]: Malformed response from 192.48.96.2
>Feb  8 08:31:14 vlsivie named[116]: Malformed response from 137.39.1.2
>( 90% of these responses come from uunet.uu.net , some from mcsun.eu.net )
>
>during which time lookups starting from root are painfully slow.
>Besides this, is there any cause to worry about it ? 
>What can lead to this behaviour ?
>

There is a bug in BIND that causes Malformed responses.  In versions
prior to 4.8.3, it could also cause core dumps.  The fix for 4.8.3
(courtesy of pma@hpsdlk.sdd.hp.com) is to initialize the count variable
(which indicates the number of items in the nsp array) to zero before
calling findns() in ns_req.c.
-- 
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-022
Phone:     (407) 729-5205              Melbourne, FL  32901