From nobody Tue Sep 27 20:53:12 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4McWzx04WGz4cvYn for ; Tue, 27 Sep 2022 20:53:17 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4McWzv5mCSz4Hk0 for ; Tue, 27 Sep 2022 20:53:14 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 28RKrDiE004322 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 27 Sep 2022 15:53:13 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 28RKrDEa004321; Tue, 27 Sep 2022 15:53:13 -0500 (CDT) (envelope-from mike) Message-Id: <202209272053.28RKrDEa004321@mail.karels.net> To: freebsd-net@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: getaddrinfo error for existing host without requested address family List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4319.1664311992.1@mail.karels.net> Date: Tue, 27 Sep 2022 15:53:12 -0500 X-Rspamd-Queue-Id: 4McWzv5mCSz4Hk0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.70 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_NA(0.00)[karels.net]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; HAS_REPLYTO(0.00)[mike@karels.net]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net] X-ThisMailContainsUnwantedMimeParts: N I recently noticed the following behavior: % ping6 redrock ping6: Name does not resolve % host redrock redrock.karels.net has address 10.0.2.2 redrock.karels.net mail is handled by 10 mail.karels.net. % ping6 nonexistenthost ping6: Name does not resolve The first error message is misleading, because the name *does* resolve, but has no AAAA record, and it is the same error message as for a name that truly does not exist. The problem comes from the set of error codes that getaddrinfo() returns in these two cases. The problem did not exist with gethostbyname(), which has separate error codes for the two (although gethostbyname did not have provision for IPv6, it handled cases like domain names and mail domains without IPv4 addresses). getaddrinfo() uses a richer set of error codes than gethostbyname(), but still misses this case. However, looking at , I see #if 0 /* Obsoleted on RFC 2553bis-02 */ #define EAI_ADDRFAMILY 1 /* address family for hostname not supported */ #endif ... #if 0 /* Obsoleted on RFC 2553bis-02 */ #define EAI_NODATA 7 /* no address associated with hostname */ #endif I don't know why these two were omitted from the update to RFC 2553, but the first seems to me to be the correct error for an existing name without an address for the requested address family. Also, that is the error message produced by Linux (Ubuntu 22.04.1). NetBSD and OpenBSD produce the second of these two errors for a host without the requested address. But they also produce the same error when a name does not exist. RFC 2553bis-02 has timed out, and is replaced by RFC 3493, which is also missing EAI_ADDRFAMILY. These are informational RFCs, not specifying an Internet standard. I propose re-enabling EAI_ADDRFAMILY and using it for the situation where a name exists but does not have an address in the requested family. This would make the error in the example less misleading, and would behave the same as Linux in this regard. The change to netdb.h is trivial, but getaddrinfo() needs a little more work because it uses the NS_* errors from internally and then translates. But it will benefit from greater accuracy in other cases as well (e.g. "out of memory" rather than "Name does not resolve"). Comments? I have a change in progress, but wanted to float the idea before I finish it and put it into review. Mike