From dan@calafia.beach.net  Mon Mar 23 23:10:05 1998
Received: from calafia.beach.net (newguy.beach.net [206.16.184.132])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06198
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 23 Mar 1998 23:10:04 -0800 (PST)
          (envelope-from dan@calafia.beach.net)
Received: (from dan@localhost) by calafia.beach.net (8.8.7/8.8.5WWW) id XAA07548; Mon, 23 Mar 1998 23:10:06 -0800 (PST)
Message-Id: <199803240710.XAA07548@calafia.beach.net>
Date: Mon, 23 Mar 1998 23:10:06 -0800 (PST)
From: dan@dpcsys.com
Reply-To: dan@dpcsys.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: bug in gethostbyname 2.2.5
X-Send-Pr-Version: 3.2

>Number:         6121
>Category:       bin
>Synopsis:       gethostbyname(3) no longer returns NO_DATA for MX records
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    peter
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 23 23:20:01 PST 1998
>Closed-Date:    Thu Jul 13 06:16:01 PDT 2000
>Last-Modified:  Thu Jul 13 06:19:04 PDT 2000
>Originator:     Dan Busarow
>Release:        FreeBSD 2.2.5-RELEASE i386
>Organization:
DPC Systems
>Environment:
				NA ?
	

>Description:

	

	gethostbyname is documented to return NO_DATA when given a hostname
	that has no A record but does have some other RR, specifically an
	MX record in my case.  This has been working though I think the
	latest release I know for a fact that it works on is 2.1.5, maybe
	2.2-R.  I'll see if I can bring it any closer to the present.

	The following code demonstrates the problem.

>How-To-Repeat:
	Run with an argument of the host to check, i.e. ./tgethost beach.net
	(which succeeds, beach.net has an A record) or ./tgethost penofin.com
	(which fails, penofin.com only has an MX record.  It should return NO_DATA)


	

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <netdb.h>

extern int h_errno;
char errbuf[200];

main(int argc, char **argv) 
{
	struct hostent *he;
	char host[64];
	long rc = 0;
	int error = 0;
	
	strcpy(host, argv[1]);

	sprintf(errbuf, "%s.", host);
		
	he = gethostbyname(errbuf);
	if(he == (struct hostent *)NULL)
	{
		switch(h_errno)
		{
			case HOST_NOT_FOUND:
				printf("|%s| HOST_NOT_FOUND\n", errbuf);
				error = 1;
				break;
			case NO_RECOVERY:
				printf("|%s| NO_RECOVERY\n", errbuf);
				error = 1;
				break;
			case TRY_AGAIN:
				printf("|%s| TRY_AGAIN\n", errbuf);
				error = 1;
				break;
			case NO_DATA:
				printf("|%s| NO_DATA\n", errbuf);
				error = 0;
				break;
		}
	}

	printf("%s %s\n", host, error ? "is bad" : "is good");
	if(error)
		printf("error is %s\n", hstrerror(h_errno));
	
	exit(0);
}

>Fix:
	
	

	I'll look when I have time but this *must* have shown up
	elsewhere.  I see a related outstanding PR for gethostbyname
	failing with high file descriptors.

	My FD_SETSIZE is 256 and open_max is 64.

	Dan
>Release-Note:
>Audit-Trail:

From: "Greg A. Woods" <woods@zeus.leitch.com>
To: freebsd-gnats-submit@freebsd.org, dan@dpcsys.com
Cc: woods@planix.com
Subject: Re: bin/6121: gethostbyname(3) no longer returns NO_DATA for MX records
Date: Wed, 01 Apr 1998 14:39:41 -0500

 Yes, that's true.  Something's amiss.
 
 The resolver library in the BIND-4.9.6 does return NO_DATA as it
 should (must, actually), but both FreeBSD's and NetBSD's resolvers are
 broken in this respect (and arguably in some other respects too!  ;-).
 
 If you want a compliant resolver one possible work-around is to
 obtain the BIND-4.9.6 distribution and build libresolv.a from it
 and statically link your application with it (you'll also have to
 be careful to compile against BIND's headers too!).
 
 -- 
 							Greg A. Woods
 
 +1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

From: "Greg A. Woods" <woods@zeus.leitch.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: bin/6121: gethostbyname(3) no longer returns NO_DATA for MX records
Date: Wed, 01 Apr 1998 14:46:54 -0500

 PR # bin/5306 should be closed with a pointer to this more complete one.
 
 -- 
 							Greg A. Woods
 
 +1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

From: Dan Busarow <dan@dpcsys.com>
To: "Greg A. Woods" <woods@zeus.leitch.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/6121: gethostbyname(3) no longer returns NO_DATA for MX records
Date: Thu, 2 Apr 1998 18:46:37 -0800 (PST)

 On Wed, 1 Apr 1998, Greg A. Woods wrote:
 > The resolver library in the BIND-4.9.6 does return NO_DATA as it
 > should (must, actually), but both FreeBSD's and NetBSD's resolvers are
 > broken in this respect (and arguably in some other respects too!  ;-).
 
 OK, so what changed in the libc resolver code between 2.1.5 and now?
 
 > If you want a compliant resolver one possible work-around is to
 > obtain the BIND-4.9.6 distribution and build libresolv.a from it
 > and statically link your application with it (you'll also have to
 > be careful to compile against BIND's headers too!).
 
 Thanks for the suggestion, that did get me going.  But it would
 really be nice to have libc do the job correctly :)
 
 Dan
 -- 
  Dan Busarow                                                  714 443 4172
  DPC Systems / Beach.Net                                    dan@dpcsys.com
  Dana Point, California  83 09 EF 59 E0 11 89 B4   8D 09 DB FD E1 DD 0C 82
 

From: woods@zeus.leitch.com (Greg A. Woods)
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: bin/6121: gethostbyname(3) no longer returns NO_DATA for MX records
Date: Tue, 7 Apr 1998 14:54:16 -0400 (EDT)

 [ On Thu, April 2, 1998 at 18:46:37 (-0800), Dan Busarow wrote: ]
 > Subject: Re: bin/6121: gethostbyname(3) no longer returns NO_DATA for MX records
 >
 > On Wed, 1 Apr 1998, Greg A. Woods wrote:
 > > The resolver library in the BIND-4.9.6 does return NO_DATA as it
 > > should (must, actually), but both FreeBSD's and NetBSD's resolvers are
 > > broken in this respect (and arguably in some other respects too!  ;-).
 > 
 > OK, so what changed in the libc resolver code between 2.1.5 and now?
 
 It would seem that the BIND 4.9.6 resolver code has been merged into
 FreeBSD-current and 2.2.x-stable, but obviously they didn't do it 100%
 
 > Thanks for the suggestion, that did get me going.  But it would
 > really be nice to have libc do the job correctly :)
 
 I agree, but I've more or less given up on the *BSD's getting the
 resolver to work correctly, esp. in face of the fact that they are
 trying to satisfy many conflicting goals, including the ancient file
 access, NIS access, etc., as well as DNS lookups, all with the same
 API.
 
 -- 
 							Greg A. Woods
 
 +1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Responsible-Changed-From-To: freebsd-bugs->	peter 
Responsible-Changed-By: phk 
Responsible-Changed-When: Mon Apr 27 00:00:43 PDT 1998 
Responsible-Changed-Why:  
->peter 

From: Alexander Langer <alex@cichlids.com>
To: freebsd-gnats-submit@freebsd.org, dan@dpcsys.com
Cc:  
Subject: Re: bin/6121: gethostbyname(3) no longer returns NO%
Date: Sun, 21 Nov 1999 15:02:25 +0100 (CET)

 Hello!
 
 This has been fixed in current releases (probably with bind8?):
 
 alex:~/prs $ cc -o tgethost pr.c
 alex:~/prs $ ./tgethost beach.net
 beach.net is good
 alex:~/prs $ host beach.net
 beach.net has address 206.16.184.129
 beach.net mail is handled (pri=10) by mail.beach.net
 alex:~/prs $ host penofin.com
 penofin.com mail is handled (pri=10) by mailman.BEACH.NET
 alex:~/prs $ ./tgethost penofin.com
 |penofin.com.| NO_DATA
 penofin.com is good
 alex:~/prs $ 
 OA
 Alex
 
 
State-Changed-From-To: open->closed 
State-Changed-By: nbm 
State-Changed-When: Thu Jul 13 06:16:01 PDT 2000 
State-Changed-Why:  
The audit trail indicates that this problem went away quite some time 
ago, possibly with the import of bind 8. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6121 
>Unformatted:
