Forum Discussion
Authenticating to a RoDC is unsuccessful
- Thank you again Lain for your quick and thorough response.
I have now resolved the issue and I am feeling quite stupid about it. The workstations (both of them) I was testing with were configured for DirectAccess. As the NLS is not available on the network, it was trying to connect via Direct Access and hence using NRPT to resolve the domain name, additionally DirectAccess was not able to reach the Domain Controllers, and as it therefore failed to connect, it was causing the DNS issues.
I have removed the DirectAccess configuration for the workstation and things started working as expected.
I am going to mark this response as the best answer, but I do want you to know that it was in no small part due to your assistance. I would not have come to this conclusion without the hints you have provided and your guidance with troubleshooting. Sincerely, thank you very much, I was really struggling.
Okay, so I've done some more homework but it left me with a great area around the non service discovery-related DNS records, for which I can't find documentation as clear as that for service location records (which I linked previously). As such, I figured it'd be faster just to knock up an RODC quickly.
The short version is that it is indeed as I said before (in relation to the MS doco, of couse), which is you do not get an NS or SOA record for an RODC, only for the writables.
I didn't speak to A or PTR records but here's another "short version": Both exist for the host but not the domain/forest name, which directly contradicts the old TechNet post you've linked above.
Here's a quick screenshot showing the writable (testdc01.robertsonpayne.net) and the RODC (rodc01.robertsonpayne.net) where you can see - as per the MS article in DNS service location records - that the RODC only features within the site discovery scopes, not the wider domain/forest scopes.
With respect to marrying up the subnet definition (192.168.2.0/24) from the first command and the ipconfig from the second (192.168.200.0/24), they aren't the same subnet associations. But then, I know you obfuscated the details so I'm not sure if that's an oversight or not. Just figured it was worth a quick mention.
If they don't match then that would result in the clients trying to talk across the site, but as I say, it may be just an issue in this post.
I'd make sure that:
- The site-specific service locator DNS records do indeed resolve against the RODC;
- Check the output of nltest /dsgetdc:yourdomain.local on the RODC and clients (clients may fail it from what you've said);
- Check the output of nltest /dnsgetdc:yourdomain.local /site:****Isolation /sitespec (where ****Isolation is your site name of the RODC from above);
- Check the System event log on the clients.
The /dnsgetdc variation could prove interesting from the client as you might get nothing back or possibly a writable domain controller via automatic site coverage (though you shouldn't.) This test specifically relates to which domain controllers have registered service location records specifically within the ****Isolation site in DNS.
If you do get more than just your RODC back in the dnsgetdc variation, then that's going to be one issue (or the issue.)
Cheers,
Lain
My DNS resource records essentially match the screenshot you have posted, and the nltests returned pretty much what you'd expect, correctly working on the RoDC with the correct site and domain information, likewise on my server in the same network, but the client is still unable to find the domain.
I think I have narrowed down the issue, but still not sure what I am overlooking, and it doesn't make sense.
If I run NSLOOKUP and search for the domain (local.domain.com), it lists the (writable) DCs, which we have determined is what is expected. However, if I attempt to ping the domain it cannot be found. It doesn't resolve the name.
If I ping the full DNS name of the DC (PDC.local.domain.com), it still fails to resolve the name.
Back on the RoDC and connected/working member server, I can ping both the domain name and the full DNS name of the DC. The DC and Member Server are both configured to use the DNS server on the RoDC.
So given this information, I opened up the network to allow the client workstation to connect to the DNS in the Corporate Site. The workstation still fails to resolve the name of the DC or Domain.
* The workstation can successfully ping the DC by IP Address.
* The workstation can successfully resolve other DNS zones from my DNS server (Domain.com, Domain.local, etc) and the forwarded requests to the internet come back successfully (i.e. ping http://www.google.com) but just cannot resolve local.domain.com.
There must be something I'm overlooking, but I do not know what that could be.
No worries! It's always a relief when you find a solution, and there aren't any silly ones.
You wont be the last person to be caught out by name resolution policies, and as of Server 2016, there's now also DNS Server policies to add into the mix of "things you can't see that are undermining you." Lots of fun to be had troubleshooting DNS in this day and age.
Cheers,
Lain- Thank you again Lain for your quick and thorough response.
I have now resolved the issue and I am feeling quite stupid about it. The workstations (both of them) I was testing with were configured for DirectAccess. As the NLS is not available on the network, it was trying to connect via Direct Access and hence using NRPT to resolve the domain name, additionally DirectAccess was not able to reach the Domain Controllers, and as it therefore failed to connect, it was causing the DNS issues.
I have removed the DirectAccess configuration for the workstation and things started working as expected.
I am going to mark this response as the best answer, but I do want you to know that it was in no small part due to your assistance. I would not have come to this conclusion without the hints you have provided and your guidance with troubleshooting. Sincerely, thank you very much, I was really struggling. No worries.
First, are the clients able to reach both UDP 53 and TCP 53 of the RODC as well as writable domain controller you just opened up access to?
If it's only UDP 53 and not TCP 53, you will run into issues with queries that have results sets larger than 512 bytes, as the Windows DNS client will cut over to TCP 53 and re-issue the query by default in such circumstances.
I only mention that as an aside though, as for the explicit host query for "pdc.domain.local", that shouldn't/wouldn't have been big enough.
Given your member server is passing all the tests, I'm more suspect on the workstation side of things, specifically, what questions they're asking.
Putting the quick check from above aside then, can you run the following for me from an impacted workstation within a PowerShell console? Administrator rights are not required.
Get-DnsClientGlobalSetting; nslookup -type=ALL domain.local. <IP-of-pdc.domain.local> nslookup pdc.domain.local. <IP-of-pdc.domain.local> nslookup rodc.domain.local. <IP-of-pdc.domain.local>I'm curious to know what resolves and what does not. I've also mentioned search suffixes before, and the command on line 1 will show any that are configured. Here's an example of the output from line 1.
Here's example output for line 5 (which asks for all matching record types, making the bottom part of the results a bit busy, but useful) using my own test environment:
You should see your "pdc.domain.local" in the results, all things being equal. PS: I don't need to see these results, it's just something for you to check given you said "pdc.domain.local" isn't resolving from the clients even when talking directly to "pdc.domain.local".
Be sure to include the trailing period after each hostname as show on lines 3, 5 and 7. This is important as it instructs the DNS client to not append any client search suffixes.
So, if we let the IPv4 address of your "pdc.domain.local" = 192.168.1.1, then an example using line 3 from above would look like:
nslookup domain.local. 192.168.1.1You can also use the -debug switch on nslookup to see what impact devolution is having (though this requires leaving the trailing period out.) For example, slightly changing line 3 from above to the following will show if the initial question is actually for domain.local or something else based on any search suffixes.
nslookup -debug domain.local 192.168.1.1Cheers,
Lain