Microsoft KB Archive/247681

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 12:50, 21 July 2020 by X010 (talk | contribs) (Text replacement - """ to """)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Knowledge Base

Article ID: 247681

Article Last Modified on 2/28/2007


  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT 4.0 Service Pack 1
  • Microsoft Windows NT 4.0 Service Pack 2
  • Microsoft Windows NT 4.0 Service Pack 3
  • Microsoft Windows NT 4.0 Service Pack 4
  • Microsoft Windows NT 4.0 Service Pack 5
  • Microsoft Windows NT 4.0 Service Pack 6
  • Microsoft Windows NT 4.0 Service Pack 6a

This article was previously published under Q247681


When you use a Microsoft Domain Name System (DNS) server to resolve client queries for Internet hosts, some domain names may not resolve. Some of the domain names which may be affected include, but are not limited to:


This problem occurs under the following circumstances:

  • A Microsoft DNS server on the inside of the firewall queries an authoritative name server on the outside of the firewall for a record.
  • The external DNS server that replies to the request has a different source IP address than the address to which the query was sent.


This problem occurs because some implementations of DNS include a load balancing feature. In implementations such as this, the server that answers a query outside the firewall can be different than the server to which the query was originally addressed.

Under these circumstances, a firewall may discard the reply from the external DNS server. The packet is discarded because the internal host (the DNS server inside the firewall) originally opened the connection to a different destination IP address than the IP address the reply was received on (the first external DNS server). This causes the reply from the external DNS server to never be received on the DNS server on the inside of the firewall.


To work around this problem:

  1. Have the DNS server that is unable to resolve some of the domain names set the "Forwarders" option to a DNS server external to the firewall. The forwarders option will cause the internal DNS server to do a recursive query to an external DNS server, which will cause the reply to be from the same source IP address that the query was sent to.
  2. Set a rule on the firewall to allow any inbound traffic destined for port 53 to the IP address of the internal Microsoft DNS server. With this setting, the firewall will not drop the replies even though they are from a different source address than the query was sent to.


This problem does not typically occur on a Microsoft DNS server that is authoritative for a zone which services external queries from the Internet. The reason for this being that the rule mentioned in workaround 2 is already set by necessity. An alternative, but equally likely, cause of this issue on Windows NT 4.0 is that the authoritative DNS server for the queried domain is located behind a firewall that blocks all DNS queries from source ports under port 1024.

The workaround is to modify the port on which your Windows NT 4.0 DNS server send its DNS queries. Windows NT 4.0 DNS by default sends DNS queries on source port 53. Use the following registry value to modify the send port for DNS.

Non-port-53 operation: This allows a firewall of port 53 and while still having the server go out and query the world. Anyone running a server on a firewall who is not interested in incoming traffic may be interested. You need to set the SendOnNonDnsPort registry key to get non-53 sends. If you set this to a specific port > 1024, you actually run on that port; any < 1024 true value means you bind to any port.


Value Name: SendOnNonDnsPort
Data Type : REG_DWORD
Data : Appropriate port # (53 is default) (port numbers are in decimal)

NOTE: This key does not exist by default.

Additional query words: Checkpoint, Firewall 1

Keywords: kbprb KB247681