Subject: (IPng 6749) getaddrinfo() return value ai_canonname on errors

From: Jun-ichiro itojun Itoh <[email-masked]>
Date: Mon, 16 Nov 1998 19:27:26 +0900

Hello, I have a tiny question about ai_canonname member in
	struct addrinfo.

	What is the value held in ai_canonname, when AI_CANONNAME is specified
	and canonical name (PTR record) is not found?
	From the textual description (quoted below) I believe this to be NULL.
	Is it correct?

	I'm curious about this because gethostbyname() puts the hostname
	specified by the caller into h_name member of struct hostent,
	when PTR record is not found.  If ai_canonname is relevant to h_name,
	we may have to set the hostname specified by the caller to
	ai_canonname.

itojun

--- bsd-api-new-04
If the AI_CANONNAME bit is set in the ai_flags member of the hints
structure, then upon successful return the ai_canonname member of the
first addrinfo structure in the linked list will point to a null-
terminated string containing the canonical name of the specified
nodename.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Craig Metz <[email-masked]>
Date: Sat, 01 Jan 2000 08:03:04 -0500

>	and canonical name (PTR record) is not found?

  I interpreted ai_canonname differently than you have. Remember that
res_search() takes a name argument like "foo" and starts a loop of making it
into a FQDN and querying that name for records, so you might have transactions
like:

foo.bar.foo.org.		-> NXDOMAIN
foo.foo.org.			-> IN A 1.2.3.4, IN AAAA 3ffe:1234::42

  From my read of the (POSIX) spec, I decided that it was allowable to simply
take the query that succeeded and extract the resulting FQDN from it. So
calling getaddrinfo on "foo" with AI_CANONNAME set will return ai_canonname
being "foo.foo.org."

  This approach also saves a DNS transaction. If you want to get the reverse
name (e.g., to do a forward/reverse DNS matching check), all you have to do is
feed your result back into getnameinfo(). If AI_CANONNAME returned the reverse
name, it seemed to me like this would be a less clean interface; getaddrinfo
should be the forward lookup, and getnameinfo should be the reverse lookup, so
a better approach would then be to eliminate AI_CANONNAME altogether.

  My definition gives both AI_CANONNAME and the sequence of calling
getnameinfo() after getaddrinfo() reasonable meanings.

									-Craig