8 hours ago8 hr This one has cost us more hours than I'd like to admit. A remote site or a patrol car connects back to the main network through a cellular router. The tunnel is up and you can ping the domain controllers by IP, but names won't resolve. The person in the car gets slow or failed logons, Group Policy doesn't apply, and mapped drives break. Often the cause is the router's own DNS forwarder answering for your internal domain before the question ever reaches your DCs. Here's how we diagnose it and the fixes that have worked for us. Gather this first Admin access to the cellular or edge router's LAN and DNS settings, either locally or through its cloud management portal. The internal AD DNS domain (we'll use contoso.local) and the DC IPs (for example 10.10.1.10 and 10.10.1.11). The remote site's subnet (for example 10.10.40.0/24). Domain admin rights for AD Sites and Services and DNS changes. Why the router gets in the way Lots of small routers, including some cellular ones, run a dnsmasq-style DNS forwarder for their LAN. That forwarder has a "local domain" configured for its own DHCP clients, and it's authoritative for that domain. Any name in that domain it doesn't know gets an immediate NXDOMAIN instead of being forwarded upstream. Some devices also treat .local specially. If the router's local domain is set to your AD domain, or covers it, every lookup for dc01.contoso.local or the _ldap._tcp.dc._msdcs.contoso.local SRV records gets "does not exist" straight from the router. The pattern that gives it away is that public names resolve, internal hostnames fail instantly (not a timeout), and querying the DC directly works. Prove it from a client From a machine at the remote site, compare what the router says with what the DC says. # Which DNS servers did DHCP hand out? Get-DnsClientServerAddress -AddressFamily IPv4 # Ask the default resolver (probably the router) Resolve-DnsName dc01.contoso.local # Ask the DC directly across the tunnel Resolve-DnsName dc01.contoso.local -Server 10.10.1.10 # The record domain members actually need to find a DC Resolve-DnsName _ldap._tcp.dc._msdcs.contoso.local -Type SRV -Server 10.10.1.10 If the first query fails with "DNS name does not exist" and the direct query to the DC succeeds, the local forwarder is your problem. If the direct query fails too, stop and fix the tunnel, routing or firewall first (UDP and TCP 53 to the DCs). Fixing the router There are three ways to go. I've listed them in the order I'd try them. Change the router's local domain Set the router's LAN local domain to something that can't collide with AD, such as lan. The router stops claiming authority over contoso.local and forwards those queries upstream. This is what fixed our case. It was a single setting, pushed to every router in the group. Forward the internal zone to the DCs If the router supports per-domain forwarding (split DNS), send the AD zone and the relevant reverse zones to the DCs and leave everything else on the normal upstream. In raw dnsmasq terms it looks like this. # Forward the AD zone and its reverse zone to the domain controllers server=/contoso.local/10.10.1.10 server=/contoso.local/10.10.1.11 server=/40.10.10.in-addr.arpa/10.10.1.10 # Do not answer authoritatively for the AD domain # (make sure no local=/contoso.local/ or domain=contoso.local line exists) Vendor GUIs usually call this something like "DNS forwarding rules," "split DNS" or "custom DNS servers per domain." Hand out the DCs as DNS servers You can also have the router's DHCP give clients the DCs as their DNS servers. It's the cleanest option for domain members, but name resolution then depends entirely on the tunnel. If the cellular link or VPN drops, clients lose all DNS, public names included. For vehicles and kiosks that still need the internet when the tunnel is down, I'd stick with one of the first two options. Tell AD about the remote subnet Even with DNS fixed, domain members on a subnet AD doesn't know about can't work out which site they're in. They may pick a DC across the country, and logons and Group Policy get slower. Add the subnet and tie it to a site. New-ADReplicationSite -Name "Branch-North" New-ADReplicationSubnet -Name "10.10.40.0/24" -Site "Branch-North" If the remote site has no DC of its own, associating the subnet with the site that has the nearest DCs is fine. Add the reverse zone while you're in there A missing reverse zone won't break logons, but it makes troubleshooting misleading. nslookup complains about the server name, logs show IPs instead of names, and some applications care about it. Create one per remote subnet. Add-DnsServerPrimaryZone -NetworkId "10.10.40.0/24" -ReplicationScope "Forest" Then make sure DHCP or the clients register PTR records. Is it actually fixed? Run ipconfig /flushdns first so you aren't looking at a cached NXDOMAIN, then run these. Resolve-DnsName dc01.contoso.local Resolve-DnsName _ldap._tcp.dc._msdcs.contoso.local -Type SRV nltest /dsgetdc:contoso.local nltest /dsgetsite gpupdate /force nltest /dsgetsite should return the site you created, and /dsgetdc should find a DC without a long delay. Things that tripped us up Windows caches negative answers. After we fixed the router, clients kept failing for a while because they'd cached the NXDOMAIN. Flush DNS on the client before you decide the fix didn't work. If the router is managed from a cloud portal, a local change can be overwritten at the next sync. Make the change in the group or template, not on one box. We've seen the same problem at more than one site. If one fleet of routers had the setting wrong, assume every fleet configured from the same template does too, and check them all. .local is reserved for multicast DNS, which is one reason some devices handle it specially. It isn't worth renaming a domain over, but keep it in mind when a Mac or a consumer device acts strangely. If the remote subnet overlaps something else you route, DNS will look broken when it's really routing. Run the direct DC query first. These days, when internal names fail instantly but the DC answers fine when asked directly, the router's local domain is the first thing I look at.
Create an account or sign in to comment