Bug#133668: marked as done (libc6: getaddrinfo ai_canonname output broken)
Your message dated Sun, 19 Dec 2004 23:22:55 +0900
with message-id <81d5x6tlj4.wl@omega.webmasters.gr.jp>
and subject line libc6: getaddrinfo ai_canonname output broken
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 13 Feb 2002 06:18:00 +0000
>From raeburn@raeburn.org Wed Feb 13 00:18:00 2002
Return-path: <raeburn@raeburn.org>
Received: from 209-6-22-64.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (raeburn.org) [209.6.22.64]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16asjw-0006hQ-00; Wed, 13 Feb 2002 00:18:00 -0600
Received: from rsx-11.raeburn.org ([2002:d106:1640:1:2e0:63ff:fe50:4f22])
by raeburn.org (8.11.3/8.11.3) with ESMTP id g1D6HwZ21711;
Wed, 13 Feb 2002 01:17:58 -0500 (EST)
Received: from raeburn by rsx-11.raeburn.org with local (Exim 3.34 #1 (Debian))
id 16asjt-0000hz-00; Wed, 13 Feb 2002 01:17:57 -0500
From: Ken Raeburn <raeburn@raeburn.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libc6: getaddrinfo ai_canonname output broken
X-Reportbug-Version: 1.42
X-Mailer: reportbug 1.42
Date: Wed, 13 Feb 2002 01:17:57 -0500
Message-Id: <E16asjt-0000hz-00@rsx-11.raeburn.org>
Delivered-To: submit@bugs.debian.org
Package: libc6
Version: 2.2.5-3
Severity: normal
According to RFC 2553, the AI_CANONNAME flag means the first returned
addrinfo structure's ai_canonname field points to the canonical name.
IMNSHO, that means CNAME RR processing, not PTR lookups from a
randomly chosen address associated with the host. Especially since
the host may have multiple addresses, which each have different names
in their PTR records. And if an address can be looked up, there is a
canonical form of the name, even if there aren't any PTR records.
(What it should mean if anything other than DNS is in use, I don't
know, but if DNS is in use, and the names aren't provided through
other means, the RFC description should apply.)
In the rfc2553bis-05 draft, and the new Open Group spec, it says that
if the canonical name cannot be determined, ai_canonname will be the
hostname argument or a copy of it. A numeric representation of one of
the addresses is just wrong.
I don't think either specification says anything about what
ai_canonname should be for returned structures after the first.
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
struct addrinfo hints = {.ai_flags = AI_CANONNAME, .ai_socktype = SOCK_STREAM};
int main (int argc, char *argv[])
{
char buf1[BUFSIZ];
struct addrinfo *ap, *ap2;
int err;
char *hname;
if (gethostname (buf1, sizeof(buf1)) != 0) {
perror("gethostname");
return 1;
}
hname = (argc > 1) ? argv[1] : buf1;
err = getaddrinfo(hname, "500", &hints, &ap);
if (err) {
fprintf(stderr, "getaddrinfo(%s): %s\n", hname, gai_strerror (err));
return 1;
}
printf("getaddrinfo(%s):\n", hname);
for (ap2 = ap; ap2; ap2 = ap2->ai_next)
printf("%p:\n\tfamily = %d\t\taddr = ...\n\tcanonname = %s\n",
ap2, ap2->ai_family,
ap2->ai_canonname ? ap2->ai_canonname : "(null)");
return 0;
}
% ./addrinfo-test raeburn.org
getaddrinfo(raeburn.org):
0x804a618:
family = 10 addr = ...
canonname = 2002:d106:1640::1
0x804a670:
family = 10 addr = ...
canonname = 3ffe:1ce1:0:fe30::1
0x804a6c8:
family = 2 addr = ...
canonname = 209-6-22-64.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com
0x804a730:
family = 2 addr = ...
canonname = 18.101.0.225
%
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux rsx-11 2.4.16 #3 Wed Dec 12 23:39:39 MST 2001 i686
Locale: LANG=C, LC_CTYPE=C
---------------------------------------
Received: (at 133668-done) by bugs.debian.org; 19 Dec 2004 14:22:56 +0000
>From gotom@debian.or.jp Sun Dec 19 06:22:56 2004
Return-path: <gotom@debian.or.jp>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Cg1xY-0002ED-00; Sun, 19 Dec 2004 06:22:56 -0800
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id 429D7DEB3B; Sun, 19 Dec 2004 23:22:55 +0900 (JST)
Date: Sun, 19 Dec 2004 23:22:55 +0900
Message-ID: <81d5x6tlj4.wl@omega.webmasters.gr.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Ken Raeburn <raeburn@raeburn.org>, 133668-done@bugs.debian.org
Subject: Re: libc6: getaddrinfo ai_canonname output broken
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: 133668-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
> According to RFC 2553, the AI_CANONNAME flag means the first returned
> addrinfo structure's ai_canonname field points to the canonical name.
> IMNSHO, that means CNAME RR processing, not PTR lookups from a
> randomly chosen address associated with the host. Especially since
> the host may have multiple addresses, which each have different names
> in their PTR records. And if an address can be looked up, there is a
> canonical form of the name, even if there aren't any PTR records.
> (What it should mean if anything other than DNS is in use, I don't
> know, but if DNS is in use, and the names aren't provided through
> other means, the RFC description should apply.)
>
> In the rfc2553bis-05 draft, and the new Open Group spec, it says that
> if the canonical name cannot be determined, ai_canonname will be the
> hostname argument or a copy of it. A numeric representation of one of
> the addresses is just wrong.
>
> I don't think either specification says anything about what
> ai_canonname should be for returned structures after the first.
(snip)
> % ./addrinfo-test raeburn.org
> getaddrinfo(raeburn.org):
> 0x804a618:
> family = 10 addr = ...
> canonname = 2002:d106:1640::1
> 0x804a670:
> family = 10 addr = ...
> canonname = 3ffe:1ce1:0:fe30::1
> 0x804a6c8:
> family = 2 addr = ...
> canonname = 209-6-22-64.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com
> 0x804a730:
> family = 2 addr = ...
> canonname = 18.101.0.225
> %
Thanks for your report. I think this bug report is already resolved
these days:
gotom@moog:~/debian/glibc/bugs/133668> ./a.out raeburn.org
getaddrinfo(raeburn.org):
0x804aeb8:
family = 10 addr = ...
canonname = raeburn.org
0x804af48:
family = 10 addr = ...
canonname = raeburn.org
0x804afb8:
family = 2 addr = ...
canonname = raeburn.org
I close this report. But if you think you think it can be improved
more, please reopen it and let us know.
Regards,
-- gotom
Reply to: