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
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Thu, 28 Aug 2003 19:44:39 -0400

[ipng mailing list cc dropped due to posting restrictions, don't ask]

I suppose you might add another flag bit to control whether or not
getnameinfo() rejects the form of PTR RR you're worried about.
Interfering with DNS diagnostic code doesn't particularly worry me,
since DNS diagnostic tools probably don't use this API anyway.  But
once your API starts down the path of trying to figure out what a
"bad" PTR RR looks like, forever will it dominate your destiny.

The real problem here is that the getnameinfo() API has two very
different ways of generating results that indistinguishable to the
caller.  There really ought to be another return value which tells you
how getnameinfo() ended up generating the text string.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.