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

[itojun@iijlab.net]

	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 <dnsop-request@cafax.se>.