To verify a hostname, TCPD goes through two steps. First, it looks up the IP address (TCP connections over the internet come from numerical IP addresses rather than hostnames, rather like basic Caller ID in the phone system) to get a host name. It then looks up the host name thus obtained to get an IP address. If that IP address matches the one from which the connection is coming, we have a hostname we can use for logging and host access control. If not, there is something out of the ordinary going on and the connection is refused.
Suppose I want to restrict a service offered to just hosts within Rutgers University. I look up the IP address from which the service request is coming from. If the answer I get back is something.rutgers.edu, I still cannot trust this. It is only what is reported by the DNS server for the IP range from which the request originated. If those people are malicious, or if that server is compromised, the response that the host is within rutgers.edu could be a lie. To verify that this IP address is within Rutgers, a lookup of the host name is then done. This request then goes to the Rutgers servers. If the reverse and forward lookup produce a match, the host name is validated. If not, there may be something nasty going on and the connection is refused.
In the vast majority of cases, this hostname validation works correctly. But sometimes, hosts are incompletely registered by an ISP. Looking up a host name for a dialup IP address, for instance, will give you a host name, but looking up that host name will produce a "host not found" error. If your connections to a service of ours are being refused and we determine that this is the cause, the best resolution is to go to technical support for your ISP. Point them at this page. This description of the problem should be enough for a technically competent support person to route your problem report to someone who can resolve it. If not, you can put them in touch with us and we will demonstrate the problem and explain what needs to be done.