Blog du Tristank

So terrific that 3 of 4 readers rated it "soporific"


DNS Resolution for Internet-Facing Servers: Clingy

  • Comments 3
  • Likes

NB Ahead of time, anytime I'm referring to a “primary” or “secondary” DNS server in this blurb, I'm referring to their relative positions on the client, not the “primary/master/secondary/slave/AD-integrated” mode of the server.

You might have spotted that I spend a reasonable amount of time with ISA and Networking, and that I don't mind writing about it. This is something that comes up occasionally:

DNS resolution in Windows operates on the principle that all servers bound to a given adapter agree with each other all the time. This is why you shouldn't mix ISP DNS and internal DNS on the same adapter - it's not healthy, and actual results may vary.

Windows' DNS resolver (aka “DNS client”, but not necessarily the DNS Client service (dnscache)) is quite exhaustively documented in the Windows Resource Kit, but the short version is this:

For each adapter:
 - While the topmost DNS Server in the list responds to queries, use only that DNS Server.
 - If the highest-priority DNS Server on an adapter doesn't respond, find a responding DNS Server and use it instead (eg, until it doesn't respond).
 - If a response is ever “Name does not exist”, cease all queries on this adapter.

So, The Golden Rule: All DNS Servers On The Same Adapter Should Really Agree With Each Other.

Now, this can lead to interesting situations: If the topmost DNS fails to respond to a query, the second DNS server is queried by the client. If the second server responds, and keeps responding, then the second server is the DNS client's new best friend, and it gets a bit, well, clingy, (or at least it used to (XP was modified in SP1 / 2000 in SP3). Before these hotfixes, name resolution would “stick” to the currently-responding server.

If you follow the golden rule and only point one adapter's DNS to one set of DNS servers, you're fine, this generally won't affect you in an “it's broken” kind of way. You might end up talking to the secondary for longer than intended (eg, until reboot), but that's generally OK for a client and only mildly annoying for a server*.

However, if you make the mistake of mixing DNS sets on the same adapter - for example, AD DNS and then ISP DNS as primary and secondary, you'll probably end up with some weird, glitchy behaviour.

For example, if your internal DNS server is shut down, rebooted or otherwise has the cable kicked out for a short while and the DNS client does a query, for the next 15 minutes (or forever, without the above fixes), it'll only talk to the ISP DNS server. If it's asking questions about the Internet, that's no problem, but if it's asking about AD, it's going to be told “your domain does not exist”, which might make it understandably upset. It won't ask for a second opinion from other DNS servers, because it just got an authoritative response, and the response was “no“, which means that the query stops at this point, and your client/server/IP-enabled refrigerator can't find the AD domain any more. Much Fun Will Ensue*.

For a single-NIC ISA Server that's doing the cache-only thing, this means that you only have the following options:

  • Use Internal DNS for External Name Resolution
    • If your internal DNS infrastructure can do Internet names, just point the DNS on the adapter to the internal DNS server, and you're done.
  • Use Internal DNS and use an Upstream Proxy
    • One of the cool things that a proxy can do is resolve names on behalf of a client. This works when your proxy is routing to an upstream proxy too. Fix suggested:
      292018 Slow Response from Downstream ISA Server Using Web Proxy Chaining
  • Host a DNS server on the ISA box itself, point ISA to itself
    • Make the ISA a Secondary Server for the internal zone, and use Forwarders or Root Hints to resolve internet names.

If ISA is dual-homed, there's generally no problem because you can have two sets of disagreeing DNS Servers - Internet DNS on the external NIC, internal DNS on the inner NIC. Voila.

(Updated with an example).

  • Very cool option there of hosting a DNS server as a secondary for the internal zone and setting up the forwarders on that DNS server to be the ISP/external ones. That is an option I hadn't thought of in the past.

  • You too can authenticate users across multiple disconnected organizations.

  • A question from Ashok: I've been trying to find out if one can use RADIUS to authenticate web proxy clients