We have a company.local domain name and also a DNS server. Lets say IP of this server is 192.168.1.1 and we have a DR site which has a replication between main DC and it has IP 192.168.1.2 , On the client site, we distribute DNS servers primary 192.168.1.1 secondary 192.168.1.2 but when i ping company.local on the client side it forcefully goes to the secondary DNS server and resolves from there. When i do ipconfig /flushdns and ping again it goes the primary, everytime i use ipconfig /flushdns domain name resolves from other DNS. Is this how it should be or doesn’t it has to resolve from primary everytime, if no communication with primary then go to secondary?

Thanks in advance

5 Spice ups

Do you really mean that it resolves from the second DNS server (query is sent there)?
Or do you mean the response is of the second domain controller?

2 completely different things.
DNS server use - dependent on operating system but windows 10 as an example could use either and will continue to use it until it stops working.
There is no issue with this, in a working AD environment all DNS servers should have the same information.

DNS name resolution - the AD domain name record in DNS will have multiple A records one for the IP of each Domain controller in the network. the request will resolve to any. It’s round robin across all queries.
For info this is not how logon server is determined etc - those services do not use simple dns record.

For optimization AD sites and services should match the network e.g. 2 sites defined (main/DR) and the DCs located in the correct site.

2 Spice ups

Your AD has 2 DCs, so an nslookup company.local will resolve BOTH IPs. This is correct.

As to why your DNS picks primary or secondary, this is how it works, it doesn’t use primary then fail back to secondary when primary is down, it’s a preference order, but whichever replies first answers.

Please read here

1 Spice up

First of all, thank you for your answers. Let me explain the situation more clearly. We have two VPN groups: VPN Group A can communicate with both the main site and the DR site, while VPN Group B can only communicate with the main site and has no access to the DR site. Most users are assigned to VPN Group B. As a result, when users connect via VPN Group B, their PCs cannot receive group policies, password policies, domain join settings, etc., because they can’t reach the DR site. But if windows would resolve domain from primary DNS i guess there wouldn’t be a problem. For example, when I try to ping the domain name (company.local), the request is sent to the secondary DNS server, which is located at the DR site. Since VPN Group B cannot communicate with the DR site, the request fails. The main issue here is that Group B should be able to communicate with the DR site — I’m aware of that — but the situation still seems strange to me. As far as I know, DNS requests are supposed to go to the primary DNS server first.

1 Spice up

Then this is just a design issue.
Only assign accessible DNS servers to clients.
in an Active Directory environment all clients must have access to ALL domain Controllers.

Do not block access to the DC/DNS server in the DR location.

AD does not just use simple hostname resolution for its services, even if it did it is still possible that a client would be given the IP of the DC in the DR site even from other DNS servers.

Rod has provided the detailed link that explains this is not the case.

Check sites and services is correct as even though it is a bad idea, clients should still function for logon/GPOs etc if sites and services directs them to the main site DC.

2 Spice ups

Incorrect. And I’ve linked to a topic to specifically cover this. Please read it.

You may set a preference, but all DNS servers are queried at the same time and the first to respond, or the last one cached will be the one used.

As far as GPO and policy, if both sites have an active read/write domain controller, and they are actively syncing, then it shouldn’t matter what DC the client uses.

Firstly I don’t understand why this would be restricted, secondly, what does the DR site have to do with policies, if the client can talk to AD in general, they should still be applying policies, the issue you may be facing could be related to offline caching. If the clients use a VPN after login, then the client logged in with cached credentials, if policies are at logon, they may not apply because the user has already logged in before activating the VPN.

This may be related to how you have sites and services configured, though I have no understanding why you would limit users from the DR site in the first place, especially if you only have 1 DC per site.

I expect whatever problems you face (which themselves are not clear since your focus is on DNS), that @matt7863 is likely correct, this issue is because of your design choice.

Perhaps instead of saying what you think the issue is, you tell us what problem you want to fix or what issues you face and we can help you with a solution instead.

1 Spice up

Thank you for your comments and ideas. I already know that there is a design issue since clients can’t talk with DR site, then DR site stays there for nothing :smiley: Im new at the company it hasn’t even been 2 months. Who knows how long clients cant talk with DR, but i fixed it now. The thing that i wondered when i ping company.local it doesn’t go primary DNS firstly it just selects randomly. And i learned that it is how it works as you guys also mentioned “You may set a preference, but all DNS servers are queried at the same time and the first to respond, or the last one cached will be the one used.” So that was my question like is this not normal or this is how it works, and i got the answer thank you guys.

1 Spice up

If you do

nslookup company.local you will get back the IPs of ALL DCs. Any of these IPs can return on a ping company.local.

Whichever replies first is the one that client will use, until they reboot or flush the DNS cache.

If you are happy with your answer, please mark a best answer for this topic.

1 Spice up