Force a Windows Server 2008 DNS Conditional Forwarder to use TCP Only

domain-name-systemwindows-server-2008

We've set up a tunnel to a partner firm. Part of their security policy insists that our DNS queries are TCP only (UDP will not be routed).

We're able to use dig +tcp and verify that queries are resolved correctly, but our own AD-integrated (Server 2008) DNS servers use UDP for the forwarded query, which will timeout and reuslt in a SERVFAIL back to the originating client.

The settings for conditional forwarders make no provision for protocol selection:
Server 2008 Conditional Forwarder

RFC 1123 says

a DNS resolver or server that is sending a non-zone-transfer query
MUST send a UDP query first.

…but this has been replaced in 5966 by

A resolver SHOULD send a UDP query first, but MAY elect to send a TCP
query instead if it has good reason to expect the response would be
truncated if it were sent over UDP

This doesn't bode well if I'm on Server 2008 (the last RFC was from 2010). Does anyone know of a way I can force my forwarder to use TCP only (or at least first)? Is it possible in any other DNS implementations, in case I have to set one up as an intermediary?

Best Answer

There is no way to turn UDP off in Microsoft DNS Server (check dnscmd documentation).

This restriction on UDP packets seems unreasonable and sure their firewall is flexible enough to accept an exception that your servers are allowed to send requests through UDP port 53.

Whenever the RFC says "SHOULD", you'd better follow what it says to avoid running into unspecified/unpredictable behavior. The correct way is to only use TCP after a UDP with a truncated response has been received.

RFC 1035 (regarding preferred method):

UDP is not acceptable for zone transfers, but is the recommended method for standard queries in the Internet.

RFC 2181 (regarding UDP truncated resposes):

Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies.

They'd better have a very good reason for not allowing UDP 53 (extremely unlikely).

Related Topic