Subject: RFC2553 API: getnameinfo: ambiguous result due to malicious PTR setting

From: [email-masked]
Date: Thu, 28 Aug 2003 08:43:28 +0900

getnameinfo(3) handles both numeric and FQDN notation of the address,
	which is very good.  i'm happy about this API.  however, i have certain
	worry so i'd mumble here.

	when (malicious) PTR record like below is configured, there's no
	way for the user of getnameinfo(3) to detect if (a) there was no
	PTR record and therefore getnameinfo is returneing a numeric notation,
	or (b) there was a malicious PTR record.

1.0.0.127.in-addr.arpa.	IN PTR	10.1.1.1

	char addr[NI_MAXHOST];
	struct sockaddr *sa;	/* AF_INET, 127.0.0.1 */
	getnameinfo(sa, salen, addr, sizeof(addr), NULL, 0, 0)

	then "addr" will contain 10.1.1.1, which looks like a numeric IPv4
	address.  therefore programmers would think like (a) - there was no
	PTR record and "sa" contains 10.1.1.1.

	if we want to be proactive (to protect normal applications), we could
	reject such PTR responses.  however, if we reject those, we will be
	hiding certain data on the DNS (i.e. DNS diagnostic tool written with
	getnameinfo(3) will not be able to access raw DNS data).

	one way to solve this issue is to use NI_NAMEREQD flag, which is
	cumbersome.

	char addr[NI_MAXHOST];
	struct sockaddr *sa;	/* AF_INET, 127.0.0.1 */
	if (!getnameinfo(sa, salen, addr, sizeof(addr), NULL, 0, NI_NAMEREQD))
		/* PTR record is there */
	else
		getnameinfo(sa, salen, addr, sizeof(addr), NULL, 0, 0)
		/* it is numeric */

	any solutions, comments, whatever, is welcome.

itojun
--------------------------------------------------------------------
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: Zefram <[email-masked]>
Date: Thu, 28 Aug 2003 09:20:04 +0100

>	getnameinfo(3) will not be able to access raw DNS data).

getnameinfo(3) is not suitable for use in a DNS diagnostic tool anyway.
get{addr,name}info(3) implement a name<=>address mapping which is defined
in a way that in part uses DNS but has other elements also.  (How many
hosts do you know that still have an /etc/hosts file providing part of
the mapping?)  get{addr,name}info(3) should be consistent with each other,
providing a consistent two-way mapping as far as possible; things that
look like dotted-quad addresses should not be returned by getnameinfo(3)
as hostnames, because getaddrinfo(3) will not treat them as hostnames.

-zefram
-- 
Andrew Main <[email-masked]>