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