Resolving IP addresses
 

While programming the IP resolution code for incoming connections on my project mud, a from-scratch C++ project in which use I 'getnameinfo', I noticed that my host name didn't resolve (into "somewhere.internet.com") and I got the string of the IP instead (something like 123.456.789.012). When I tested it from the localhost, the host name resolved. The man page states its normal behavior for 'getnameinfo' to return the string IP if the resolution fails. But I was curious, so I took a look through the logs on my Rom2.4 mud (which uses gethostbyaddr instead) and noticed that it appears the IP addresses don't get resolved on at least 60-70% of the connections there.

I'm not sure if it's always been this way and I never noticed before, or if this is abnormal behavior ... but should I be getting the human-readable form of the location of the connection more than ~30-40%? Does anyone know how, exactly, the resolution request works, and why some names don't resolve? Not knowing what's really going on behind the scenes, I would think that "success" should be much higher than what I'm seeing ...

Thanks

Re: Resolving IP addresses
 

There are 2 parts of DNS involved here, the normal "A" record which turns a hostname into an IP address, and the rDNS (reverse DNS) "PTR" record which turns an IP address back into a hostname. Many hostnames may point to the same IP address, but the IP address can only resolve back to one hostname.

Take Google's public DNS for example:
The rDNS record is set by whoever owns your server's IP block. Usually you have to go through your ISP or hosting provider to change it. Some hosting providers give you a place in their control panel where you can set the rDNS without needing to contact anyone.

EDIT: also, not all IPs have an rDNS record.

Re: Resolving IP addresses
 

Since my example doesn't show this, I should add that when forming an "in-addr.arpa" address from an IP address, you reverse the order of the octets.

(This octet-reversing behavior is pretty common when forming hostnames out of IP addresses. It's done to query a DNS RBL, for example.)

Re: Resolving IP addresses
 

OK, that might explain it then. I'm going to guess that I'm seeing more IP's that don't have a rDNS record. If I understand it right then, from the way you've explained it - getnameinfo() must use the rDNS. Am I correct in assuming that the rDNS info (host name in this case) is different than the info returned from a WHOIS query? Because I've found that I can still get the "owner info" on the IP addresses that fail getnameinfo().

Re: Resolving IP addresses
 

Almost certainly -- that's what rDNS is for, and I'm not aware of any other remotely reliable way to do it.

Speaking of reliable, you can't trust an rDNS entry by itself. It can be anything, including invalid and non-resolvable junk. Mail servers see spammers with spoofed "gmail.com" rDNS entries with extreme frequency. A good implementation will do the rDNS lookup ("gmail.com"), and then confirm the answer by looking up the returned hostname (if any) and comparing the returned IP address(es) to the IP we're trying to find out about.

I don't know as much about whois from a technical standpoint. I know it's a separate (though related) system from DNS, and I'm pretty sure that it's much more centralized than DNS. Most or all whois servers are aggressively rate-limited and forbid you from using them for automated lookups, making them a poor choice for learning about IPs on a large scale.

Re: Resolving IP addresses
 

Ok, thanks Pymeus - that helps a bunch!

Re: Resolving IP addresses
 

If you want to make things even more interesting don't forget to run a dual stack set-up so that you can support IPv6 as well as the more familiar IPv4 (with 4 times as many bits in the addresses).

If you haven't got IPv6 connectivity natively there are way around it - I'd recommend a visit to the pair of guys over at SIXXS ( You may end up sending your IPv6 packets over an IPv4 link to a tunnel endpoint provided by one of the hosting companies donating the bandwidth, so obviously there is a bit of a round trip but it works and the various companies involved want your traffic!

With a standard tunnel brokered using their system I now have as many IPv6 addresses on my subnet as there are on the whole of the IPv4 net - say goodbye to NAT and gain a fixed IPv6 address (unless you have a setup that deliberately changes some of the bits of the address on a random basis)!

If you do that you can make use of those AAA records that you get!