DNS issue : DHCP relay + VLANs + multiple AD Sites

2011-09-01

Question

_{Thursday, September 1, 2011 12:37 PM}

Hi,

We're having an issue with our primary DNS Server... Let me explain the Network.

We have 6 VLANs :
VLAN clients : 192.168.0.0/24
VLAN ToIP : 192.168.2.0/25
VLAN AD (with DHCP relay on routers for VLAN Clients and ToIP) : 192.168.16.0/24
VLAN Admin : 192.168.19.0/25
VLAN Europe 1 : 192.168.73.0/25
VLAN EUrope 2 : 192.168.104.0/25

We have 3 AD Sites :
Site Paris : VLANs clients, ToIP, AD, Admin
Site Europe 1 : VLAN Europe 1
Site Europe 2 VLAN Europe 2

Each site has its own domain controller with AD/DNS/DHCP...
IPs are :
Paris : 192.168.16.1
Europe 1 : 192.168.73.1
Europe 2 : 192.168.104.1

For all clients in site Paris (VLANs clients, ToIP, Admin), the address of the DNS server is set by DHCP to point to 192.168.16.1, which is correctly authoritative for these VLANs.

The problem we are experiencing is that all clients from Paris sites (VLANs clients, ToIP, Admin) are resolving the AD domain MYDOMAIN.LOCAL as 192.168.73.1 (Europe 1) instead of 192.168.16.1 (Paris).
Round robin is disabled on all DNS Servers and netmask ordering is enabled.

I know that a DNS server returns the closest result for a DNS query, and that's why clients in Europe 1 resolve MYDOMAIN.LOCAL as 192.168.73.1, clients in Europe 2 resolve MYDOMAIN.LOCAL as 192.168.104.1, and others servers in the VLAN AD resolve MYDOMAIN.LOCAL as 192.168.16.1.
But the problem is that all clients from VLANs "clients", "ToIP", or "Admin" resolve MYDOMAIN.LOCAL as 192.168.73.1... I know they're not on the VLAN 192.168.16.0 but it's the closest subnet...

A NSLOOKUP for the local domain with a computer in 192.168.0.0/24 gives :
Server : paris.mydomain.local
Address : 192.168.16.1

Name : mydomain.local
Addresses : 192.168.73.1
* 192.168.104.1*
* 192.168.16.1*

Has anyone already seen this ? Do you have any idea ?

Thanks a lot!

Thibaut

All replies (31)

_{Monday, September 5, 2011 3:19 PM ✅Answered}

For the results to not rotate after enabling Round Robin, indicates *possibly* a configuration change is preventing it from performing properly. I'm not sure what you've changed, but at this time, I'm considering that a *possible* factor.

Other than believing the longest bit match is making it resolving to the 73.1, I'm fresh out of ideas, and I'm not sure what else to suggest.

You may consider calling Microsoft support for further assistance. Here's the link if you choose this route:
http://support.microsoft.com/common/international.aspx?RDPATH=dm;en-us;select&target=assistance

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Thursday, September 1, 2011 2:33 PM}

For AD aware clients, they do not depend on round-robin or netmask ordering for locating a DC for authentication. You need to ensure that your AD Sites and Services has been configured correctly. Sites needs to be defined with associated subnet objects linked to them.

Visit anITKB.com, an IT Knowledge Base.

_{Thursday, September 1, 2011 2:54 PM}

It has already been done.

AD Site Paris is associated with subnets VLAN Clients, VLAN ToIP, VLAN Admin, and VLAN AD.

Result of "gpresult /scope computer /r" :
RSOP data for MYDOMAIN\MYACCOUNT on MYCOMPUTER : Logging Mode

OS Configuration:            Member Workstation
OS Version:                  6.1.7601
Site Name:                   Paris
Roaming Profile:             N/A
Local Profile:               C:\Users\myaccount
Connected over a slow link?: No

COMPUTER SETTINGS

*    CN=MYCOMPUTER,OU=SUBOU,DC=MYDOMAIN,DC=LOCAL*
*    Last time Group Policy was applied: 9/1/2011 at 4:25:10 PM*
*    Group Policy was applied from:      PARIS.MYDOMAIN.LOCAL*
*    Group Policy slow link threshold:   500 kbps*
*    Domain Name:                        MYDOMAIN*
*    Domain Type:                        Windows 2000*

And nslookup on mydomain.local still answers :
Server: paris.mydomain.local
Address: 192.168.16.1

Name:    mydomain.local
Addresses: 192.168.73.1
*          192.168.104.1*
*          192.168.16.1*

I've built many networks with multiple AD Sites and VLANs, but it's the first time I have this problem...

_{Friday, September 2, 2011 6:17 AM}

Let's look at it this way. You have the following AD Sites and Subnet objects created and associated with a current AD Site:

Each site has its own domain controller with AD/DNS/DHCP... IPs are :
Paris : 192.168.16.1
Europe 1 : 192.168.73.1
Europe 2 : 192.168.104.1

But you have all these subnets (below), some of which YOU HAVE NOT defined as subnet objects and associated with any of the AD SItes you created above.

We have 6 VLANs :
VLAN clients : 192.168.0.0/24
VLAN ToIP : 192.168.2.0/25
VLAN AD (with DHCP relay on routers for VLAN Clients and ToIP) : 192.168.16.0/24
VLAN Admin : 192.168.19.0/25
VLAN Europe 1 : 192.168.73.0/25
VLAN EUrope 2 : 192.168.104.0/25

To make sure you want a specific DC be the logon server for a specific subnet with a specific AD Site, you MUST associate that subnet with a Site that has the DC you want to be the logon DC for those clients.

Just to be clear, Subnet Prioritization and Round Robin has NOTHING to do with AD CSE (client side extensions) looking for a DC in an AD Site, UNLESS, there are multiple DCs in the site, OR the client's IP subnet has NOT been associated with an AD Site. Any AD enabled application or service will use AD SItes FIRST before they use subnet priortization or round robin.

And nslookup is not AD SIte aware, therefore is not a good tool to determine what an AD client CSEs should use when it queries for a DC.

I highly suggest to design your IP SUbnets, associate them with the intended AD Site, and re-enable or put back to default Subnet Priortization and Round Robin.

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Friday, September 2, 2011 6:26 AM}

Here's more info on AD Sites and how the logon process works:

The DC Locator Process, The Logon Process, Controlling Which DC Responds in an AD Site, and SRV Records
Published by Ace Fekay, MCT, MVP DS on Jan 3, 2010 at 10:30 AM 1285 0
http://msmvps.com/blogs/acefekay/archive/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records.aspx

Thread Question: "how to control sequence of domain controllers a client computer logging on"
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/77bc547f-4d0d-4a0c-b463-359b1c771a81/

Managing sites in Active Directory involves adding new subnet, site, and site link objects when the network grows, as well as configuring a schedule and cost for site links. You can modify the site link schedule, cost, or both, to optimize intersite replication. When conditions no longer require replication to a site, you can remove the site and associated objects from Active Directory. Jan 6, 2003 ... Lot's of good info on the KCC, Bridgheads, TCP/IP settings, ISTG, etc. Most of it applies to Windows 2008 & 2008 R2, too.
http://technet.microsoft.com/en-us/library/bb727051.aspx

I hope you find this info helpful.
Ace

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Friday, September 2, 2011 7:17 AM}

Thanks for your answers.

But maybe I'm not clear enough :-/

Each VLANs and AD Sites are associated correctly (I did it via the Active Directory Sites and Services MMC). Here's the config :
Paris :
      VLAN AD 192.168.16.0/24
      VLAN Clients 192.168.0.0/24
      VLAN ToIP 192.168.2.0/25
      VLAN Admin 192.168.19.0/25

Europe 1 :
VLAN Europe 1 192.168.73.0/25

Europe 2 :
VLAN Europe 2 192.168.104.0/25

My problem is not about association between AD Sites and VLANs as it's correctly configured (a SET in command prompt shows LOGONSERVER=\PARIS.MYDOMAIN.LOCAL when I'm in Paris, LOGONSERVER=\EUROPE1.MYDOMAIN.LOCAL when I'm in Europe 1 etc....). My problem is really just a DNS issue where VLANs not directly on the subnet of the associated AD Site controller resolve queries to Europe 1.

Just to be sure to be clear, here are 2 examples of what's hapening.
Let's say I'm in Europe 1, my computer IP is 192.168.73.10 distributed by DHCP, on the same subnet as the DC :
LOGONSERVER=\EUROPE1.MYDOMAIN.LOCAL (correct and configured with AD Sites and Services)
ping to mydomain.local => response is 192.168.73.1 (correct)
ping to proxy.mydomain.local (a cname of mydomain.local) => response is 192.168.73.1 (correct)
nslookup mydomain.local => authoritative server is europe1.mydomain.local and addresses are 192.168.73.1, then 192.168.16.1, then 192.168.104.1 (all correct)

Now let's say I'm in Europe 2, my computer IP is 192.168.104.10 distributed by DHCP, on the same subnet as the DC :
LOGONSERVER=\EUROPE2.MYDOMAIN.LOCAL (correct and configured with AD Sites and Services)
ping to mydomain.local => response is 192.168.104.1 (correct)
ping to proxy.mydomain.local (a cname of mydomain.local) => response is 192.168.104.1 (correct)
nslookup mydomain.local => authoritative server is europe2.mydomain.local and addresses are 192.168.104.1, then 192.168.16.1, then 192.168.73.1 (all correct)

Now I'm in Paris, with an Admin session on another server with IP 192.168.16.20, on the same subnet as the DC :
LOGONSERVER=\PARIS.MYDOMAIN.LOCAL (correct and configured with AD Sites and Services)
ping to mydomain.local => response is 192.168.16.1 (correct)
ping to proxy.mydomain.local (a cname of mydomain.local) => response is 192.168.16.1 (correct)
nslookup mydomain.local => authoritative server is paris.mydomain.local and addresses are 192.168.16.1, then 192.168.73.1, then 192.168.104.1 (all correct)

But now I'm in Paris, on a computer with IP is 192.168.0.10 distributed by DHCP, NOT on the same subnet as the DC :
LOGONSERVER=\PARIS.MYDOMAIN.LOCAL (correct and configured with AD Sites and Services)
ping to mydomain.local => response is 192.168.73.1 (incorrect)
ping to proxy.mydomain.local (a cname of mydomain.local) => response is 192.168.73.1 (incorrect)
nslookup mydomain.local => authoritative server is paris.mydomain.local and addresses are 192.168.73.1, then 192.168.104.1, then 192.168.16.1 (the authoritative and answering server is paris.mydomain.local, which is correct, but this server tells me that mydomain.local IPs are 192.168.73.1 (europe1), then 192.168.104.1 (europe2), and finally 192.168.16.1 (himself in paris)).

So, why does Paris' DC server tells clients computers on VLAN 192.168.0.0/24 associated with AD Site Paris 1, that mydomain.local IP is not paris.domain.local as it's paris that answers my query ? And it's the same thing for Subnets 192.168.19.0, 192.168.2.0...

Thibaut

_{Friday, September 2, 2011 2:43 PM}

I don't see a subnet object in your list of subnets under any of your AD Sites for 192.168.0.0. However, it appears the Paris computer with an IP in that subnet apparently did use a DC to logon in Paris. Did you associate this subnet to the Paris AD Site? If not, the CSEs may have used subnet priortization to find the DC.

And as I mentioned, nslookup, nor ping, has the intellegence to lookup the AD "_sites" records in DNS to know which AD site it's in.

The other sites that you did test it on, used subnet priortization to resolve a record that is closest to it's own subnet, which nslookup (which uses it's own built-in client side resolver), and ping (which uses the computer's client side resolver) will use.

Therefore, when pinging or using nslookup, the computer in Paris with an IP of 192.168.0.10 does not know that it is part of an AD Site. Remember, nslookup and ping does not have that intelligence, such as the CSEs, to resolve or figure out the fact it is part of an AD site.

Therefore, ping and nslookup uses subnet priortization first, then round robin.

Here's a better explanation of Subnet Priortization:

DNS Subnet Priortization & DNS Round Robin
http://msmvps.com/blogs/acefekay/archive/2010/05/29/dns-and-subnet-priortization-amp-dns-round-robin.aspx

Thread on the subject:
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/32f820bf-b871-4b76-9c9b-12413e33801a

Hope that helps,
Ace

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Friday, September 2, 2011 3:11 PM}

Thanks for answer, but again (it seems that I'm definitly not clear), all my VLANs are linked to correct subnets, as show this picture :

The registry key "site-name" under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" in my computer shows "Paris".

The problem is NOT AD Sites related, it's DNS or network related, I don't know...

I've already read your second link. IIS is installed on each DC and hosts a .pac file. I configured via GPO all clients to use http://proxy.mydomain.local/ as automatic configuration script. I then tried to put 3 A entries ("proxy") instead of 1 CNAME ("proxy"), but I still have the same problem. PCs in Europe 1 resolve proxy as europe1 server IP (correct), PCs in Europe 2 resolve proxy as europe2 server IP (correct), but PCs in Paris resolve proxy as europe1 server IP (incorrect).

Any idea regarding the DNS and/or a network related wrong configuration ?

_{Friday, September 2, 2011 3:34 PM}

I was under the impression you believe it is AD Site related. Your AD Sites seem to be working fine.

Using pings and nslookups are not site aware, so we'll take AD Sites out of thepicture.

Maybe then I'm still not clear what your exact concerns are? Are you trying to make the client "find" a specific server or other resource in it's own AD Site?

However, if your concerns is that ou want a specific machine with a network file share to respond to a client machine in it's own site or logon DC's site, then I would suggest to use DFS. That is Site aware and will return a resource in the client's site.

As for why the pings and nslookups behave as such, my blog has specifs on subnet priortization and round robin, and how they work together.

Oh, btw, it appears from your previous posts that you have a 'proxy.mydomain.local' CNAME that is pointing to the LdapIpAddress record (all the A records with 'same as parent'). We don't recommend doing this. Each DC registers an LdapIpAddress record. The LdapIpAddress record is how the CSEs 'find' DCs for GPOs, DFS, and other functions.

From observation of the info you've provided, it appears that this record, the mydomain.local RR that it's pointing to, is a gateway, assuming so since it appears it's a Proxy server. Does that mean it is a gateway? Does that mean that Proxy, TMG, etc, is installed on your DCs? If I were to imply that, then that means your DCs are multihomed (more than one unteamed NIC, IP address and/or RRAS is installed). Is this correct? If so, that is a highly undesirable configuraiton and we highly recommend not to multihome a DC. It causes numerous issues with DNS registration and AD functions and communications.

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Friday, September 2, 2011 4:00 PM}

Yes DFS works perfectly. We use it for network shares. And we use DFS to replicate our .pac file on each DC ;-)

Ok so I remove duplicated A entries and just create 1 CNAME (I think a read an article saying to create multiple A instead of 1 CNAME, but I trust you).

But the problem still resides... We have only 1 activated NIC on each server (no team and only 1 IP), no gateway software, no proxy software...

Really strange situation, I've never had and never heard about this issue before, I don't understand...

_{Friday, September 2, 2011 6:18 PM}

Curious, what is the purpose of the CNAME record? Can you elaborate on why it's there, and why it is pointing to the LdapIpAddress?

Looking back at your original post, it appears you're just concerned with non-AD records resolution:

The problem we are experiencing is that all clients from Paris sites (VLANs clients, ToIP, Admin) are resolving the AD domain MYDOMAIN.LOCAL as 192.168.73.1 (Europe 1) instead of 192.168.16.1 (Paris).
Round robin is disabled on all DNS Servers and netmask ordering is enabled.

I know that a DNS server returns the closest result for a DNS query, and that's why clients in Europe 1 resolve MYDOMAIN.LOCAL as 192.168.73.1, clients in Europe 2 resolve MYDOMAIN.LOCAL as 192.168.104.1, and others servers in the VLAN AD resolve MYDOMAIN.LOCAL as 192.168.16.1.
But the problem is that all clients from VLANs "clients", "ToIP", or "Admin" resolve MYDOMAIN.LOCAL as 192.168.73.1... I know they're not on the VLAN 192.168.16.0 but it's the closest subnet...

A NSLOOKUP for the local domain with a computer in 192.168.0.0/24 gives :
Server : paris.mydomain.local
Address : 192.168.16.1

Name : mydomain.local
Addresses : 192.168.73.1
192.168.104.1
192.168.16.1

With what you're describing above, I don't see a problem with the way nslookup or ping is resolving it. The resolver service is dooing what it's suppose to be doing.

But what concerns me, is you're playing around with the LdapIpAddress records. I'm not totally understanding why you are doing this?

If it has something to do with a Proxy server, and if it is a Microsoft product, such as ISA or TMG, you can publish the proxy info into a GPO for clients in specific sites.

Therefore, I'm not totally understanding the problem?

Ace

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Saturday, September 3, 2011 10:02 AM}

The problem is PCs in VLAN Clients in Paris (192.168.0.0/24), linked with AD Site Paris (like the Paris DC) resolve mydomain.local as the europe1.mydomain.local IP instead of paris.mydomain.local...

For the CNAME it's simple :
As I told you, we replicate our .pac file on each DCs. And we just use this .pac in IIS installed on these DCs.
This way, we can put a GPO on client saying that Internet Explorer uses http://proxy.mydomain.local/proxy.pac. So each Site has the same IE parameter, but each one points to its own Site .pac file.
We use this system for WSUS too. We have a GPO saying that clients' WSUS server is msupdates.mydomain.local (a CNAME too). But with this DNS issue, clients in Paris are connecting to the Europe 1 server ! They then download all their updates from this same server over the WAN, which is very problematic.
I know the simple answer is to change the GPO to make clients point to their FQDN DCs, but we will still have this DNS resolution issue.

We don't have any proxy server on our server. The .pac file is just a javascript file tolding IE which proxy IP to use. Our proxies are dedicated equipments (our firewalls btw...)

And the resolver is not doing it's correctly.
Nslookup actually respond this :
Server : paris.mydomain.local
Address : 192.168.16.1

Name : mydomain.local
Addresses : 192.168.73.1
192.168.104.1
*192.168.16.1

When it should be responding this :
Server : paris.mydomain.local*
Address : 192.168.16.1

Name : mydomain.local
Addresses : 192.168.16.1
192.168.73.1
192.168.104.1

With the Paris DC in first position !

_{Saturday, September 3, 2011 5:52 PM}

I really don't understand why you're pointing your Proxy address to the LdapIpAddress, nor installing IIS on a DC. Whether the PAC file is replicated or not, I would suggest to use something other than a DC for this purpose. You're altering the LdapIpAddress function,

It's also a security best practice to not install additional applications or exposable services, other than DNS, DHCP and WINS. IIS. There are other viable solutions instead of installing IIS on a DC for this purpose.

The easiest solution I see is put in the actual address of the Proxy in a GPO in respective OUs for each location. This way you know each client in a specific location gets their specific settings. This is of course assuming your OU structure is designed based on locations, which is usually an easier method to control applications deployment, WSUS, etc, for each specific location.

But your main concern is why nslookup is not always resolving with 192.168.16.1 as the first response.

As said, nslookup is not AD Site aware. If you run your nslookup, hit enter, get a response, then hit the arrow UP, then run it again consecutive times, you will see the responses rotate. This is the result of Round Robin.

And yes, the client side resolver and nslookup (as already stated has its OWN built-in resolver), uses Subnet Priortization, but if there is no "closest" match, it will use Round Robin.

Therefore, when a non-AD aware application is involved in a resolution request (such as nslookup and ping), and if both Round Robin and Subnet Priortization are enabled, Round Robin wins.

What is closest match you ask? It's based one the subnet mask. Windows 2003 and newer all default to use Class C subnets as a first response, then Class B, then Class A.

If you want to change this behavior, you can do so by altering the registry on EACH DNS server.

My blog, posted above, explains how to, and it also explains all the above I posted.

Also, you may want to read the following about Windows Vista & 2008 (which I posted that thread link in my previous post explaining this):

Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default:
http://support.microsoft.com/kb/968920

IMHO, I would honestly recommend to redesign your OU/GPO solution to make this work for you instead of altering default resolver and DNS server behavior.

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Saturday, September 3, 2011 6:41 PM}

First, thanks a lot for your time and your answers !

To respond to your remarks about IIS on DCs, it's only because our european sites have 1 only server. They are used for DC, IIS (to provide a local access to the .pac file instead of asking the Paris server trough the WAN, then going back with they answer, and then returning to Paris to access Internet via the proxy), print server, file server, WSUS, WDS etc...

I was sure you would tell me to redisign my OU/GPO, but it won't help resolving my DNS issue... We are already working on this, but it won't make Paris PC resolving mydomain.local as their local DC instead of the europe1.mydomain.local server IP.

I know nslookup and ping are not site aware, and as I said in my first post, round robin as already been disabled on each DNS server. When I run nslookup on mydomain.local, IP are not rotating. I ALWAYS have europe1, then europe2, and finally Paris.

You said "But your main concern is why nslookup is not always resolving with 192.168.16.1 as the first response.". But my concern is that nslookup (or ping etc) NEVER resolve 192.168.16.1 as the first response. The order is ALWAYS the same and is always europe1, then europe2, and finally Paris ! As stated, the subnet priortization should tell to the 192.168.0.0 that mydomain.local is paris.mydomain.local, but it does not, and that's what I'm trying to understand and to resolve.

_{Sunday, September 4, 2011 12:16 AM}

Ok, let's go back to your previous posts.

A NSLOOKUP for the local domain with a computer in 192.168.0.0/24 gives :
Server : paris.mydomain.local
Address : 192.168.16.1

Name : mydomain.local
Addresses : 192.168.73.1
192.168.104.1
192.168.16.1

And:

But now I'm in Paris, on a computer with IP is 192.168.0.10 distributed by DHCP, NOT on the same subnet as the DC :
LOGONSERVER=\PARIS.MYDOMAIN.LOCAL (correct and configured with AD Sites and Services)

ping to mydomain.local => response is 192.168.73.1 (incorrect)

ping to proxy.mydomain.local (a cname of mydomain.local) => response is 192.168.73.1 (incorrect)

nslookup mydomain.local => authoritative server is paris.mydomain.local and addresses are 192.168.73.1, then 192.168.104.1, then 192.168.16.1 (the authoritative and answering server is paris.mydomain.local, which is correct, but this server tells me that mydomain.local IPs are 192.168.73.1 (europe1), then 192.168.104.1 (europe2), and finally 192.168.16.1 (himself in paris)).

After re-reading your posts and symptoms, what you're seeing is default and expected behavior when resolving mydomain.local. This is because the only answers you should see are the A records for the three DCs you have, because it's resolving to the LdapIpAddress (the ones with 'same as parent') that each DC registers, therefore what it's doing is correct.

CNAMES can behave in undesirable results in some cases, for example, if the CNAME TTL is longer than the A record it points to, you will definitely get undesirable results. This is well documented, especially with some website DNS admins that incorreclty configured their website records. THere are a few out there, including cdc.gov. WHat you're doing with the CNAMES is pretty much what I'm seeing that may be occuring. The LdapIpAddresses get refreshed every 24 hours (when the Netlogon service on each DC re-registers them by default), however your CNAME may be longer or without a TTL. You can read more in the following link on this issue.

2008 server dns service failure to resolve cname:
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/bfe3a89f-7ff6-43c9-b387-0a240d891283

The 192.168.2.0 and 192.168.0.0 records shouldn't resolve, because there there are no A records for them. If they did, there would be problems with AD communications and certain functions.

Recommendations

CNAMES can be problematic. If I may suggest, remove all CNAME records, and create A records, such as proxy.mydomain.local, with the actual IP addresses you want, and you should get the expected results. You can even take it a step further when you redesign your OU/GPO solution and create specific A records (not CNAMES) for each location so you have more finite control that each location gets their proper, respective records to the DC that you choose, such as:

proxyeurope1.mydomain.local 192.168.73.1
proxyeurope2.mydomain.local 192.168.104.1
proxyparis.mydomain.local 192.168.16.1

I hope that helps,
Ace

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Sunday, September 4, 2011 9:53 AM}

My issue is not about CNAME resolution, it's a A resolution problem. I talked about CNAME proxy just because I have the same issue with A and CNAME. Let's forget CNAME and talk only of A records.

What is in my DNS servers for "mydomain.local":
(same as parent folder)        Start of Authority (SOA)     [133592], paris.mydomain.local.      static
(same as parent folder)        Name Server (NS)        europe1.mydomain.local.       static
(same as parent folder)        Name Server (NS)        paris.mydomain.local.       static
(same as parent folder)        Name Server (NS)        europe2.mydomain.local.       static
(same as parent folder)        Host (A)           192.168.73.1          30/08/2011 18:00:00
(same as parent folder)        Host (A)           192.168.104.1          29/08/2011 19:00:00
(same as parent folder)        Host (A)           192.168.16.1          31/08/2011 11:00:00

All entries automatically created by each DNS server when installing the DC Role.
Based on this, correct Sites and Services configuration, round robin disabled, netmask ordering enabled (and everything we've talked before), why do Paris computers do net resolve mydomain.local as 192.168.16.1 but as 192.168.73.1?

_{Sunday, September 4, 2011 5:18 PM}

What operating system is the computer in Paris?

If you alter this reg key in the client reg, does it resolve it?

Add a new registry key with the following settings:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Sunday, September 4, 2011 5:41 PM}

Already tried this registry key with no result...

Computers are Windows 7 Ent. x64 and servers are Windows 2008R2 Std.
Both have the same issue.

_{Sunday, September 4, 2011 8:24 PM}

Ok, I don't remember reading that you tried the reg key. I may have missed it.

If you enable Round Robin, then run nslookup, does it show up in the list of results, and when you hit arrow up and repeat the run a few times, does it show up at the top of the list at all?

I'm starting to believe that 192.168.73.1 is the 'longest' bit result, which is why it shows up.

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Sunday, September 4, 2011 9:03 PM}

You didn't read about the registry key because I tried it before posting here. In fact, I tried a lot of things before this post. It's like my last hope!

I've just tried activating round robin and doing 10 nslookup. The result is still the same and never rotate :-/ Even after ipconfig /flushdns

_{Sunday, September 4, 2011 10:25 PM}

I see. As for not rotating after you've enabled it, that's unusual. That may indicate something else is affecting it. I assume you've restarted the DNS server service after you've enabled it, and cleared the cache on the client side.

Additional assumptions:

Your zones are AD integrated.
There are no errors with replication or anything else in the event logs on any of the DCs or clients.
The Paris client is pointing to only the Paris DC for DNS, or at least it's the first in the DNS resolver list in the NIC.
All subnets are /24.

What else have you previously tried? Have any changes been made to any of the DC/DNS properties in regard to startup, or any other property changes?

Does it occur with all Win7 clients? Have you tested it with an XP client? If so, is the behavior the same?

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

_{Monday, September 5, 2011 7:54 AM}

Yes I restarted thee DNS Service and cleared the cache.

- My zones are AD integrated

There are no error with replication or anything else (servers or clients)
Paris clients are only pointing to Paris DC for (only 192.168.16.1)
Paris DC is /24, Paris clients are /24 (I did the same test on other Paris server in 192.168.16.0/24 and others in 192.168.19.0/25, always the same result)

Honestly, I can't list everything I've tried til now, I know there was another registry key I tried (in TCP/IP\Parameters too) which did not change anything. And no changes since months (except the installation of the server 192.168.73.1).

It occurs on Win 7 clients, Win XP clients, and 2008R2 servers.

_{Monday, September 5, 2011 5:15 PM}

Ok, thanks a lot for your help!

Thibaut

_{Saturday, January 7, 2012 1:14 AM}

Ok, thanks a lot for your help!

Thibaut

Hi Thibaut,

Did you end up resolving this issue and if so what was the final fix?

Kind Regards,

Jose

_{Saturday, January 7, 2012 10:22 AM}

Hi Jose,

Sorry but no, no final fix... Still the same issue, Paris' computers are resolving the local domain as London's server IP.

As a result, I cannot use CNAME in my DNS server, and have had to assign the proxy server address or the WSUS server address by GPO, using the sites.

Thibaut

_{Sunday, January 8, 2012 1:19 AM}

Hi Jose,

Sorry but no, no final fix... Still the same issue, Paris' computers are resolving the local domain as London's server IP.

As a result, I cannot use CNAME in my DNS server, and have had to assign the proxy server address or the WSUS server address by GPO, using the sites.

Thibaut

Thanks Thibaut. I will be looking at a similar issue this Monday for a client and will keep you posted if I make any progress.

- Jose

_{Friday, January 3, 2014 5:54 PM}

Do you have any progress about this topic?

I'm having the same problem in a domain with 15 Sites.

Servers Windows 2008 Enterprise R2

Workstations Windows 7 32/64 bits

Thanks for any reply.

_{Friday, January 3, 2014 6:33 PM}

Hi Rogerio, No I didn't solve the DNS issue. In fact, the main problem I had with this DNS resolution was that my client were not connecting to the correct DFS share because of the bad IP resolution. I finally solved this issue 4 months ago! If you have the same DFS problem, I can give you my solution on Monday with screenshots. Let me know. Thibaut

_{Wednesday, January 8, 2014 1:58 PM}

My problem more specifically is about ping to domain name. Always some dc on a unreachable subnet replies to me. About DFS shares i don't have problems yet. But would like to know your solution to have some alternative.

Thank you very much.

_{Wednesday, January 8, 2014 2:17 PM}

Here's what I've done, which seems to solve (at least temporarily) the DNS issue :
- I have re-created all DC hosts in the DNS server as a static entry (instead of dynamically created when adding the DC to the list of servers) => don't really know if it is usefull...
- In your DNS server properties, on the "Advanced" tab, check "Enable netmask ordering" and uncheck "Enable round robin"

Regarding the DFS resolution, I finally found a little option I never saw in any documentation.
Go to the properties of one of your namespace, "Referrals" tab, and in "Ordering method" choose "Exclude targets outside of the client's site.

Hope it will help you !

Thibaut

_{Tuesday, February 24, 2015 7:41 AM}

Hi Thibaut,

Did you try change mask of netmaskordering?

According to your subnet addressing, if you set LocalNetPriorityNetMask to 00001FFF, problem must gone.

Run this command on your DNS server at Paris Site and then restart DNS service:

Dnscmd /Config /LocalNetPriorityNetMask 0x00001FFF

You can get addition info about LocalNetPriorityNetMask at https://support.microsoft.com/kb/842197/en-us

Share via

DNS issue : DHCP relay + VLANs + multiple AD Sites

Question

All replies (31)

Additional resources