From owner-freebsd-current Thu Jan 2 12:44:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01203 for current-outgoing; Thu, 2 Jan 1997 12:44:51 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA01194 for ; Thu, 2 Jan 1997 12:44:46 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.8.4/8.8.2) id EAA09456 for freebsd-current@freebsd.org; Fri, 3 Jan 1997 04:44:42 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 2 Jan 1997 20:44:41 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <5ah6np$8rh$2@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199701020456.PAA20024@asstdc.scgt.oz.au> Subject: Re: Resolver Error 0 (no error) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701020846.JAA03861@uriah.heep.sax.de>, j@uriah.heep.sax.de (J Wunsch) writes: > As michael butler wrote: > >> > fetch: couldn't open FTP connection to ftp.funet.fi: Resolver Error 0 (no >> > error) >> >> > Hmpf? >> >> Best guess .. fetch is waiting for an authoritative answer and the >> nameservers who would be so are unreachable or not responding, > > Well, to the very least, ``Error 0 (no error)'' is a sad joke. Either > there's an error condition, so there should be an error code, or not. No, that's a bug in the linkage between fetch and libftpio. libftpio is not correctly passing out error codes from it's internal routines, so the higher level stuff is getting confused. > Anyway, even if so, why does fetch wait for any authoritative answer? > There's a non-authoritative answer avaiable, and all the required data > are there (CNAME record, A record for the host). > > I have seen the behaviour of host(1) hanging indefinately before, i > only didn't care. I'm afraid there's a bug in our resolver code. named, not resolver. Named verifies the authority stuff, and in this case one of the .fi servers appears to be non functional: peter@spinner[4:31am]~/bind/8/contrib/doc-115> ping ns.tele.fi PING ns.tele.fi (193.210.19.19): 56 data bytes 36 bytes from mae-east.tele.fi (192.41.177.225): Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 31da 0 0000 f4 01 1ada 192.203.228.67 193.210.19.19 [.. from Doc ..] ;; res_send to server ns.tele.fi. 193.210.18.18: Operation timed out DIGERR (UNKNOWN): dig @ns.tele.fi. for SOA of parent (fi.) failed -Peter