8

We've got a branch office with no on-site services at the moment, and we'd like to change that. The biggest goal is to setup some file servers but faster logins and DNS resolution will be welcome as well.

I'm doing some experiments with some VMs on a separate subnet/VLAN so let's say I've got forest and domain domain.com:

  1. There is a single site Office with a subnet 192.168.1/24 and a single Primary DNS zone domain.com
  2. Added a secondary site TestSite with a subnet 192.168.100/24
  3. Created 192.168.100 reverse lookup zone in DNS
  4. Created a VM Branch-DC01 running Server 2012, with IP address 192.168.100.1
  5. Added to domain.com as member
  6. Installed AD DS as a Read Only Domain Controller (RODC) in TestSite
  7. The main DNS server for Branch-DC01.domain.com is 127.0.0.1
  8. Setup DHCP scope for the new server and configured for DHCP to always update DNS
  9. Created Branch-PC01 VM running Windows 8 and added to domain.com
  10. Branch-PC01 got IP address of 192.168.100.20 from DHCP, DNS server 192.168.100.1, entry for the member in the forward lookup zone domain.com present but not in the reverse lookup zone (significant?)
  11. On Branch-PC01 executed nslookup domain.com - result came back with IP addresses of the main DCs from the Office site (192.168.1 subnet)

Now this isn't right in my mind - shouldn't it return 192.168.100.1? Or am I misunderstanding the whole concept--and how are the logons supposed to be quicker?

Do I need a separate DNS zone (how would that work without a subdomain which I don't want to create, unless required)?

Any ideas/articles which I can be pointed to would be great; I've read through a bunch of TechNet articles and am none the wiser.

Thanks

Update

Many thanks to @TheCleaner and @charleswj81 your efforts are appreciated.

I've just tried nltest and the result is the same from the branch DC and client PC:

U:\>nltest /dsgetdc:domain.com /server:Branch-DC01.domain.com
           DC: \\Branch-DC01.domain.com
      Address: \\192.168.100.1
     Dom Guid: d97516d3-4afb-4f0a-8c3f-04a800cd69fb
     Dom Name: domain.com
  Forest Name: domain.com
 Dc Site Name: TestSite
Our Site Name: TestSite
        Flags: GC DS LDAP KDC TIMESERV DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE P
ARTIAL_SECRET WS DS_8
The command completed successfully

Update 2

  1. Cleaned DNS entries so any _sites containers with TestSite has only SRV records for Branch-DC01 which after restart of the client didn't help.

  2. nltest on the client:

    `U:>nltest /dsgetdc:domain.com

           DC: \\DC01.domain.com

  Address: \\192.168.1.3

 Dom Guid: d97516d3-4afb-4f0a-8c3f-04a800cd69fb

 Dom Name: domain.com

    Forest Name: domain.com

    Dc Site Name: Office

    Our Site Name: TestSite

        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN

    DNS_FOREST FULL_SECRET WS

    The command completed successfully`

SamErde
  • 3,409
  • 3
  • 24
  • 44
hyp
  • 495
  • 4
  • 12
  • First, check on the branch PC and see which DC actually authenticated you. From a cmd line run: `echo %LOGONSERVER%`. When you says site, I'm assuming you mean ADS&S and that you have separate sites there for your branch? – TheCleaner Nov 22 '13 at 14:14
  • @TheCleaner `echo %LOGONSERVER%` came back with a hostname of one of the main DCs from the main site, yes I do have a separate Site with subnet specified and under `TestSite` -> `Servers` I can see the test DC as the only entry – hyp Nov 22 '13 at 14:18
  • Have you tested it more than once? I ask because with an RODC it uses cached login info, so if this is the only/first time it forwards the auth request to a normal DC. Oh and the other DCs, are they at least 2008? – TheCleaner Nov 22 '13 at 14:27
  • I've just restart the client PC and logged out / back in, every time the %LOGONSERVER% is one of the main office DCs. Looking at DNS it looks like NS records were generated for all DCs (branch + office) for the branch reverse lookup zone - if that's of any help? Tried deleting all but the branch DC from that zone but they just get generated again... – hyp Nov 22 '13 at 14:42
  • @TheCleaner forgot to answer about version - the main DCs are 2x Server 2008 R2 + 1x Server 2012 – hyp Nov 22 '13 at 15:23
  • OK, I asked because 2003 is quirky with RODCs in the mix. Check the SRV records in DNS for that site as well. Other than that, I'm not really sure...I was hoping one of the others in chat would know but nobody has spoken up yet. I've dealt with this in the past, but usually got frustrated with the results. There are regkeys you can set to force a particular DC but it's overkill usually. – TheCleaner Nov 22 '13 at 15:40
  • Did `Branch-DC01` ever have an IP in the `192.168.1.0/24` subnet? Or was the `Branch` site defined after the new DC was stood up? – charleswj81 Nov 22 '13 at 15:45
  • @charleswj81 as per steps in the questions I've first created the site, added the subnet then created the VM and before it first run I've set the network adapter (in Hyper-V) to the appropriate VLAN @TheCleaner "Check the SRV records" not sure where would I do that? `domain.com` -> ForestDNSZone /DomainDNSZone -> _sites -> `TestSite` -> _tcp -> has all DCs listed (the branch one as well) but they all were generated, haven't touched them – hyp Nov 22 '13 at 15:57
  • Went through all entries in DNS, any place refering to `TestSite` has only records for `Branch-DC01`, the only place different is the reverse lookup zone which still auto generates NS records for all DCs. – hyp Nov 22 '13 at 16:28
  • Have you already tried `nltest`? Maybe `nltest /dsgetdc:domain.com /server:Branch-DC01` to see what the dc locator logic determines. Or `nltest /dsgetsite` from the workstation. – charleswj81 Nov 22 '13 at 16:34
  • Why are you having DHCP update DNS? That's usually a sub-par solution if you're dealing with domain-joined Windows clients, as they will automatically update their own DNS records directly without the need for DHCP update proxying. – MDMarra Nov 22 '13 at 16:59
  • Don't try your nltest specifying /server...just do `nltest /dsgetdc:domain.com` on the test PC. I asked about the SRV records in DNS that you found because I believe that's how the client contacts a DC in that site. If they are all listed, that might be the issue. – TheCleaner Nov 22 '13 at 17:02
  • Hi, have you configured a password replication policy on the RODC? the password replication policy should be configured to cache the credentials of both the users and computers at your branch. if not they will keep being authenticated by the HQ DC. – Michael Brown Apr 16 '16 at 15:58

1 Answers1

0

It's perfectly normal for a client at one site to receive DNS resolution for the domain to a DC at a different site. This is because of all the "(same as parent)" A records for the domain forward lookup zone. Every DC is going to be listed round robin for the domain.

It's not the most ideal for DNS resolution efficiency (and can cause issues if some sites aren't available) but you can set up things like geotagged DNS to mitigate it and it's perfectly normal behavior. Once the client gets a DC, any DC, to respond, that DC will utilize the Sites and Zones configuration to fetch a DC in it's proper zone and inform the client to direct further requests against that DC. Once a client logs on, it caches its site and mostly utilizes the %LOGONSERVER% for future transactions.

duct_tape_coder
  • 826
  • 4
  • 13