Jimmy Bogard has blogged about his experiences after his hosting providers switched a number of servers from external IP addresses to NAT-ted internal ones. As Jimmy speculates, this was probably because the provider had exhausted their allocation of public IP addresses.
MSMQ and cached DNS
To get things working, they had to restart sender and receiver MSMQ servers. To explain why, here’s some background:
MSMQ makes use of two caches:
- A MSMQ-specific list of IP addresses and QMID values. This is used to quickly determine where to send acknowledgement messages back to.
- A Windows-wide list of IP addresses and hostnames. This is used by all network applications that need to resolve a hostname to an IP address. MSMQ uses this for message delivery.
- The QMID cache.
This is covered in the blog post Jimmy links to. Restarting the MSMQ service will flush this cache; entries also get removed over time.
- The Hostname cache
This is maintained by the operating system and MSMQ has no influence over it. MSMQ will keep using a particular IP address as long as the cached information is fresh. MSMQ checks at regular intervals when it can't deliver messages in case the destination's IP address is provided by DHCP and has changed through lease expiry.
There are a few things you can do to switch off MSMQ’s use of name resolution, as documented in KB 833512.
- ForceNameResolutionDirect registry value
- CacheTimeout registry value
- MaxCacheEntryTtlLimit or MaxCacheTtl registry values