Nash!Com Workspace
Database Catalog
Command Line Tools
Sync & Import Solutions
rDNS Replacement
Extended Mail Log
Special DB Fixup
Daylight Savings Fixup
Trace/Lowercase Conversion Extension
Run Special Tasks
Demo & Evaluation

Nash!Com rDNS Replacement

Reverse DNS Lookup can have a dramatically performance impact on your web presentation. Specially using NT you can run into problems that cannot be resolved using the default synchronous Reverse DNS Lookup Lotus provides for the Domlog.nsf database. It might be useful to map IP addresses into domain names and hosts. But this could lead to a very high performance impact for some clients that

  • Have no DNS entry for their proxy or requesting IP
  • and have a firewall that does not allow Netbios Status requests.

This problem is specific to Lotus Domino Servers running on Windows platforms. However this solution might also help to increase performance on other operating systems like Linux.

The solution is based on a Servertask that copies documents from standard domlog.nsf into a new Domino log database while checking the name for the requesting IP address.

This is done asynchronous and has no impact on server performance because is independent from the HTTP stack.
It uses an internal cache that not just caches the names but also the status for the request. In case an IP address has no name it will not requesting it again for the following requests. This does significantly reduce the time for resolving addresses if the IP has no DNS entry specified.

Some technical background

This section contains very technical information we found out about the webserver response time problem some customers had accessing a Domino based website.

We identified this problem as not being a Domino problem. The problem is caused by and combination of the winsock-request performed by Domino, that only occurs on NT platforms in combination with 'some' client environments if DNS Lookup is enabled in the server document.
It is not caused by Domino, but Domino is using a feature of NT that isn't working the way it should work.

Lotus Domino uses the winsock function gethostbyaddr() to resolve the requesting IP address to get the host name.

The gethostbyaddr() call uses the following sequence:
  1. Check local computer host name
  2. Check the HOSTS file for a matching address entry
  3. If a DNS server is configured, query it
  4. If no match is found, send a NetBIOS Adapter Status Request to the IP address being queried, and if it responds with a list of NetBIOS names registered for the adapter, parse it for the computer name.

Steps one and two are just local actions and are handled very fast.

Step three uses a DNS query to resolve the address via IN-ARPA PTR (address-to-name) records.
This should be fast, because it queries the local ISPs DNS server in most configurations.

If the DNS server is not authoritative for the domain and does not hold the entry in cache it makes a query to another DNS server.
But after the local DNS server found out about the address it holds it in it's cache (until time to live is reached).
Therefore subsequent queries result in a non authoritative but faster answer from the local DNS server.

Step four uses a NetBIOS Adapter Status Request (RFC 1001/1002) directly to the requesting client. This might be a performance problem, if the query has no success. Using a small winsock test program we found out that the timeout interval is approximately 5 seconds.

Lotus Domino uses gethostbyaddr() for each GET request. In most cases you have a lot of GET requests for frameset, frames and pictures.
If each of the request forces a NetBIOS Adapter Status Request that times out. If the address isn't found or timed out, it can't be cached.

If a DNS name is specified, the DNS query gets a fast response. But if no DNS entry is defined and the NetBIOS Adapter Status Request times out we get the slow answer time the customer found out using their proxy or any other client using an IP address without DNS.

It depends on the configuration of the firewall on the other side if the NetBIOS Adapter Status Request times out. The port used for this kind of lookups is port 137 and is called Netbios Name Service.

The NetBIOS Adapter Status Request Feature was introduced in NT Version 3.51 and I could not find any way to disable this feature.

MSDN Article ID: Q138086 describes this feature.

MSDN Article ID: Q138086

Windows NT 3.51: Reverse Name Resolution for WINS Clients
Last reviewed: April 30, 1997

Windows NT version 3.51 TCP/IP includes a new feature that allows a host to find out the computer name (host name) that matches a TCP/IP address; this is possible even if DHCP is being used to dynamically assign TCP/IP addresses.

Windows Sockets programs use the GetHostByAddr() call to resolve a TCP/IP address to a computer name. To accomplish this resolution, the Windows NT 3.51 GetHostByAddr() first attempts to look up the computer name by contacting a domain name server (DNS), if one is configured. If the DNS lookup does not return a host name, then GetHostByAddr() attempts to resolve the TCP/IP address to a computer name by using a NetBIOS Node Status Request as defined in RFC1001/1002. NetBIOS nodes return their name table in response. The GetHostByAddr() routine parses the name table for the computer name and returns this to the caller.

This method does not work for hosts that are not NetBIOS-capable. PTR records (that is address-to-name records) must be added to the DNS for these computers.