chytil@vlsivie.tuwien.ac.at (Chytil Georg) (02/08/91)
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 ?
FYI : I'm running primary server for vlsivie.tuwien.ac.at. ,
uunet.uu.net is a secondary (?) for at. All rootservers are at
least 300ms away ...
Georg
<-------Trust not a man who's rich in flax, his morals may be sadly lax------->
Chytil Georg Systemdamager@Dep. of VLSI (vlsivie) TU Wien A-1040 Wien Austria
chytil@vlsivie.{tuwien.ac.at,uucp} chytil@egh780.una.at +43/(0)222/58801/8146
#include <extra_disclaimer.h> Don't panic! Fax: +43/(0)222/569697piet@cwi.nl (Piet Beertema) (02/13/91)
>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 ) > >What can lead to this behaviour ? > >FYI : I'm running primary server for vlsivie.tuwien.ac.at. , > uunet.uu.net is a secondary (?) for at. All rootservers are at > least 300ms away ... One problem is that it's *not* uunet.uu.net, but ns.uu.net that is secondary server for the AT top level domain (and for many other top level domains). The addresses above are both of uunet.uu.net, not of ns.uu.net (137.39.1.3). Another problem is that in the AT zone file there is a glue record "assigning" ns.uu.net the address (192.48.96.2) of uunet.uu.net. Needless to say that this caused a mess all over the place and requires an immediate fix. The fix that Andrew Partan of UUnet posted in this newsgroup prevents such bogus addresses/assignments from showing up in the zone files on the secondary servers, but the patch for sure won't have been implemented everywhere. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
del@algol.mlb.semi.harris.com (Don Lewis) (02/14/91)
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
del@algol.mlb.semi.harris.com (Don Lewis) (02/14/91)
In article <2929@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes: >Another problem is that in the AT zone file there is a glue >record "assigning" ns.uu.net the address (192.48.96.2) of >uunet.uu.net. Needless to say that this caused a mess all >over the place and requires an immediate fix. The fix that >Andrew Partan of UUnet posted in this newsgroup prevents >such bogus addresses/assignments from showing up in the >zone files on the secondary servers, but the patch for sure >won't have been implemented everywhere. It also doesn't help primary servers when someone puts these bogus "glue" records in the primary zone file. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-022 Phone: (407) 729-5205 Melbourne, FL 32901