First, some background on my question: After troubleshooting what appeared to be a mass Trojan infestation on a network I manage, I’ve found that the default behavior of a windows domain environment can potentially expose the entire domain to malicious actions. There are a number of specific but common conditions that trigger this situation. Environment: Mix of Windows 2003 and 2008 Servers in a domain. All the affected systems were latest service packs and patches from windows updates as of 6/21/2011. Conditions: 1. “Append parent suffixes of the primary DNS suffix” is checked under Advanced TCP/IP, DNS settings for a LAN connection. 2. FQDN for the domain is a sub-domain of one of the extended registrar services, such as “foo.us.com” or “foo.uk.com.” 3. Affected client is joined to the FQDN as a domain. Problem: There appear to be conditions where a client PC will attempt to resolve a DNS A record for a host, and it will include the port number. Example, it may query for “pdc:389” or “172.16.1.10:389” for an LDAP host. When the :389 (or other port) is included, the DNS server (both MS DNS and others) strip the part before the colon. In this case it would return an A record for “389.” When that is not found, it appends the domain suffix for the connection and tries again. For example: “389.foo.us.com.” Assuming this also returns no entries, and if the “Append parent suffixes of the primary DNS suffix” is checked in the connection settings (which is default), the client will then try the parent domain as such: “389.us.com.” In this case it is resolving a name that is out of control of the organization, and could be registered by anyone. In the case of our testing, this resolves to the IP 91.213.214.122, which is malicious host. This is an issue that someone is already trying to exploit, as they have registered common port numbers such as 80, 389, 445, 25, 135, 137, etc under us.com, uk.com, and others. In the environment I manage, I had a lot of servers trying to connect to that malicious IP on multiple ports, and even sending IPv6 router solicit requests (over IPv4) to it. The person running the system at an address registered like this could accept the connections and take control of hosts. Bottom line... Why would Windows 2003 or 2008 server systems be trying to access "hosts" with the port number attached to the end, causing them to think they are hostnames that need resolving? Could this be a misconfiguration somewhere? I've been unable to find any bad settings causing it, and this affects numerous protocols. The security implications here are quite profound.

Hello, Is it with SRV records? DNS only resolves name, not ports. Are you sure this is not a side effect of the infestation? Actually one thing I see as a probelm is that you are not in control of your domain. The only thing you cannot control is the TLD but you should control your domain name as good practice. If you are a child domain of .us.com, then wheover owns the domain "us" can sell off subdomains and leave you vulnerable. Miguel Miguel Fra / Falcon IT Services Computer & Network Support, Miami, FL Visit our Knowledgebase and Support Sharepoint Site

Thanks for the reply. It is making queries for A records. It is kind of my point that it shouldn't be including port numbers in requests. Somehow, something in the system is causing it to include that. One specific example I saw was a kerberos session setup that listed the server/instance as "ldap/10.20.1.10:389". The server responded that it did not know of such a name (probably because the :389 should not be included there), and the client then started querying for A records and NetBIOS names of 10.20.1.10:389. us.com is basically run by CentralNIC. They allow numerous registrars to register domains a sub-domains. Implicit trust of one of these domains is bad, but only part of the issue. I definitely think people should be aware that using one of those as their AD FQDN could be disastrous. I am really now just trying to figure out why port numbers are included on these requests. It sounds like a config issue, but so far the configuration checks out.

Just updating the answer here. After much back and forth with MS I was finally directed to this security bulletin, which describes the exact behavior: http://technet.microsoft.com/en-us/security/advisory/971888