NetBSD Problem Report #44915

From  Thu Apr 28 12:03:05 2011
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 75B3163C481
	for <>; Thu, 28 Apr 2011 12:03:05 +0000 (UTC)
Message-Id: <>
Date: Thu, 28 Apr 2011 14:03:01 +0200 (CEST)
Subject: getaddrinfo() error code usage
X-Send-Pr-Version: 3.95

>Number:         44915
>Category:       lib
>Synopsis:       getaddrinfo() error code usage
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 28 12:05:01 +0000 2011
>Last-Modified:  Wed Dec 02 18:10:00 +0000 2015
>Originator:     Havard Eidnes
>Release:        NetBSD 5.1
	I Try, Inc.
System: NetBSD 5.1 NetBSD 5.1 (MAANEN) #12: Wed Dec 22 11:42:27 CET 2010 i386
Architecture: i386
Machine: i386
	There are a few issues with getaddrinfo() this particular PR

	 - getaddrinfo() when looking for AAAA info for a name which
           has a CNAME but where the target doesn't have AAAA returns
           EAI_FAIL ("Non-recoverable failure in name resolution").

	   I think RFC 3493 prescribes that EAI_NONAME should be
	   returned instead.

	 - getaddrinfo() makes use of the EAI_NODATA error code.
           Between RFC 2553 and RFC 3493, that error code has
           apparently been deprecated.  I have searched but not found
           the reason for this particular change; it may have come
           from the POSIX side.

	 - The error text for EAI_NONAME is perhaps a bit confusing
           and also slightly misleading ("hostname nor servname
           provided, or not known"); I have tried to think of a better
           short message which is more fitting, but the best I've come
           up with so far is "Hostname/servname/address-type not found
           or not provided", which is longer and which I'm not
           entirely happy with, but it also covers the case where
           "name exists, but not the data you were looking for".

	   No diff is provided for this particular issue.

	% ping6
	ping6: Non-recoverable failure in name resolution
	% dig aaaa
	;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0
	;; ANSWER SECTION:              1262 IN CNAME 60 IN CNAME  6583 IN CNAME

	The deprecation of EAI_NODATA can be seen by inspection in RFC

	The first hunk below removes an instance where EAI_NODATA is
	being returned, bringing us one small step closer to complying
	with RFC 3493.  EAI_NONAME is returned instead.

	The rest is so that we distinguish between "no data of
	requested type" and "(severe) lookup failure" which otherwise
	appears as the default error code.

Index: net/getaddrinfo.c
RCS file: /cvsroot/src/lib/libc/net/getaddrinfo.c,v
retrieving revision
diff -u -u -p -r1.91.6.1 getaddrinfo.c
--- net/getaddrinfo.c	26 Jan 2009 00:27:34 -0000
+++ net/getaddrinfo.c	28 Apr 2011 11:19:28 -0000
@@ -581,7 +581,7 @@ explore_fqdn(const struct addrinfo *pai,
 		error = EAI_FAIL;
 		goto free;
-		error = EAI_NODATA;
+		error = EAI_NONAME;
 		goto free;
 	case NS_SUCCESS:
 		error = 0;
@@ -1235,7 +1235,12 @@ getanswer(const querybuf *answer, int an
 		return sentinel.ai_next;

-	h_errno = NO_RECOVERY;
+	/* We could have walked a CNAME chain, */
+	/* but the ultimate target may not have what we looked for */
+	if (ntohs(hp->ancount) > 0)
+		h_errno = NO_DATA;
+	else
+		h_errno = NO_RECOVERY;
 	return NULL;

@@ -1367,6 +1372,7 @@ _dns_getaddrinfo(void *rv, void	*cb_data
 		switch (h_errno) {
+		case NO_DATA:
 			return NS_NOTFOUND;
 		case TRY_AGAIN:
 			return NS_TRYAGAIN;

From: "Christos Zoulas" <>
Subject: PR/44915 CVS commit: src/lib/libc/net
Date: Wed, 2 Dec 2015 13:09:53 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Wed Dec  2 18:09:53 UTC 2015

 Modified Files:
 	src/lib/libc/net: getaddrinfo.c

 Log Message:
 PR/44915: Havard Eidnes:
 - Convert NS_NOTFOUND to EAI_NONAME instead
   of EAI_NODATA which more inline with what other OS's do.
 - Convert NO_DATA to NS_NOTFOUND since there is no equivalent mapping
   for nsswitch (perhaps we could add one so what we could recover the exact
   error and return EAI_NODATA?)
 - If we end up following a CNAME chain that does not find any data return that
   instead of internal error.

 XXX: pullup-7

 To generate a diff of this commit:
 cvs rdiff -u -r1.110 -r1.111 src/lib/libc/net/getaddrinfo.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.