1 minute read

I came across this one today when one of our web apps in the perimeter network stopped working for external users after a switch failure on our internal network.

We run split DNS so if you ask an internal DNS server for the IP address of webapp.ourdomain.com it will tell you the private address of the perimeter webserver but if you ask a DNS server on the internet you will get the public address which is NAT’d to the ISA server which publishes the app. Now if you ask a DNS server in the perimeter network he will forward the DNS request to an internal DNS server. If the internal DNS server is unavaliable the perimeter server will use recursion to resolve the address and ultimatily end up resolving and caching the public address of the webapp. By now you can probably guess what happens.

  1. Internet user connects webapp.ourdomain.com which is resolved to 203.271.47.15
  2. The connection is NAT’d by our external hardware firewall and received by the ISA web listener / publishing rule.
  3. The ISA server resolves the name in the “To” section of the web publishing rule using a perimeter DNS server. The address is from the internal domain (ourdomain.com) so the perimeter DNS server tries to forward the request to an internal DNS server, this fails so the perimeter DNS server uses recursion to resolve the name and returns the public internet address instead of the private address of the web server in the perimeter network. We now have a loop which results on the above error being logged.

There are a couple of ways to deal with this.

  1. Disable recursion on the domain forwarding in the DNS server settings:
  2. Explicitly specify the IP address in the “To” section of the publishing rule.

Another one of those “Only in this exact and unlikely situation” type posts but oh well!

Updated: