DNS Issues – AD Domain, internal only

[TeunBeunHaas]

Hallo allemaal, ik heb een vaag probleem bij ons op kantoor. Ik ben ook al 18 jaar uit Nederland weg en mijn Nederlands schrijven is ontzettend slecht, dus ik schrijf het in Engels.

So, I have a weird DNS issue in one of my office buildings. It is not a client issue, as this is happening to all machines in the building.

We can ping on IP internally, but not on name. NSLOOKUP works fine and gives the correct results. Internal ping on host name gives straight away the error “Ping request could not find the host”. This failure comes on both host name and FQDN.

We can however ping external sources, like www.google.com, without issues.
Now, the weird thing is, ping on name fails on all machines, EXCEPT for the virtual machines and our 2 Hyper-v physical hosts. They all work fine. Our Meraki switches can ping the FQDN, but not the host name.
If I connect with Direct Access to our gateway server, then again we can ping internal resources.

In IPCONFIG /ALL, it shows the Connection-Specifix DNS Suffix correctly, but if you hoover over the LAN connection in Windows 10, it cant Identify the network.
Our DNS servers are also our DC’s and 1 of them does DHCP, in IPCONFIG, the correct settings are being applied.

I am currently at a loss, any ideas what is causing DNS/ AD network Identification to fail?


What have we tried.

1. We didnt apply any patches to the DCs during the weekend (it failed monday morning), but we did a restore of both DCs from a few days before, this didnt resolve the issue.

2. Did you turn it off and on again, yes we did.

3. We shutdown the entire network, including all switches and Fortigate firewalls. We then brought online only the SAN, both Hyper-V hosts and the DC's (both VMs). And the 2 meraki switches in the server room. I then attached 1 laptop to the same switch in the server room, still cant ping internally on name.

4. I made a brand new VM (windows 10), this one CAN ping on host name

[MAX3400]

Sinds wanneer speelt dit? Wat is er (vlak) daarvoor gebeurt aan updates / patches / changes / afvoeren&aanmaken van machines & records? Een "acute" storing zoals je die beschrijft moet een bijna exact tijdstip / constatering hebben.

Ik sluit voorlopig Hyper-V + VM's even uit van verdere troubleshooting; daar zit een ander netwerk op / in / aan dus allicht dat je hier even de "verschillen" met het gewone netwerk kan identificeren en allicht analyseren of daar de oplossing ligt.

Wat zegt een (simpele) tool als dcdiag? Treedt het issue ook op als je mogelijk 1 enkele DC en 1 enkel fysiek werkstation op 1 switch prikt zonder verdere andere zaken? Wat zegt de eventlogging van een willekeurige client? Kan een DC zijn / haar broertje wel resolven? Of andere machines in het netwerk?

Maak je gebruik van FortiDB? Van wanneer is de laatste update en welke services gebruikt je? Wat zegt "de netwerkman" over protocollen die wel/niet toegestaan & gezien worden? Heeeft iemand al eens de scope-options en (dus ook) DHCP & DNS gecontroleerd? Hoe zijn de permisies op records?

[ Voor 4% gewijzigd door MAX3400 op 20-02-2022 12:05 ]

[TeunBeunHaas]

Hola, thanks for the quick reply, will try to answer most questions as now. Currently remote, so will answer what I can.

Maak je gebruik van FortiDB? Not sure, it has been installed by external company from Canada (I am Germany based), will check with them tomorrow.

Wat zegt "de netwerkman" over protocollen die wel/niet toegestaan & gezien worden?

He was bloody brilliant, so my company fired him. Having said that, I compared the Meraki settings to other sites, all relays and routing are applied the same as in the other sites. Regarding the DCs and patching, did a complete restore from when it was definitely still working, that didnt fix the issue

Kan een DC zijn / haar broertje wel resolven? Of andere machines in het netwerk?

Yes, The DCs can ping on name, all other servers, both VM servers and physical host. They can also ping the servers in other sites.


dcdiag - I removed the company specific information


Directory Server Diagnosis


Performing initial setup:

Trying to find home server...

Home Server = eusvdc01

* Identified AD Forest.
Done gathering initial info.


Doing initial required tests


Testing server: Bonn\EUSVDC01

Starting test: Connectivity

......................... EUSVDC01 passed test Connectivity


Doing primary tests


Testing server: Bonn\EUSVDC01

Starting test: Advertising

......................... EUSVDC01 passed test Advertising

Starting test: FrsEvent

......................... EUSVDC01 passed test FrsEvent

Starting test: DFSREvent

There are warning or error events within the last 24 hours after the

SYSVOL has been shared. Failing SYSVOL replication problems may cause

Group Policy problems.
......................... EUSVDC01 failed test DFSREvent

Starting test: SysVolCheck

......................... EUSVDC01 passed test SysVolCheck

Starting test: KccEvent

......................... EUSVDC01 passed test KccEvent

Starting test: KnowsOfRoleHolders

......................... EUSVDC01 passed test KnowsOfRoleHolders

Starting test: MachineAccount

......................... EUSVDC01 passed test MachineAccount

Starting test: NCSecDesc

......................... EUSVDC01 passed test NCSecDesc

Starting test: NetLogons

......................... EUSVDC01 passed test NetLogons

Starting test: ObjectsReplicated

......................... EUSVDC01 passed test ObjectsReplicated

Starting test: Replications

......................... EUSVDC01 passed test Replications

Starting test: RidManager

......................... EUSVDC01 passed test RidManager

Starting test: Services

......................... EUSVDC01 passed test Services

Starting test: SystemLog

......................... EUSVDC01 passed test SystemLog

Starting test: VerifyReferences

......................... EUSVDC01 passed test VerifyReferences


Running partition tests on : ForestDnsZones

Starting test: CheckSDRefDom

......................... ForestDnsZones passed test CheckSDRefDom

Starting test: CrossRefValidation

......................... ForestDnsZones passed test

CrossRefValidation


Running partition tests on : DomainDnsZones

Starting test: CheckSDRefDom

......................... DomainDnsZones passed test CheckSDRefDom

Starting test: CrossRefValidation

......................... DomainDnsZones passed test

CrossRefValidation


Running partition tests on : Schema

Starting test: CheckSDRefDom

......................... Schema passed test CheckSDRefDom

Starting test: CrossRefValidation

......................... Schema passed test CrossRefValidation


Running partition tests on : Configuration

Starting test: CheckSDRefDom

......................... Configuration passed test CheckSDRefDom

Starting test: CrossRefValidation

......................... Configuration passed test CrossRefValidation


Running partition tests on : xxxx

Starting test: CheckSDRefDom

......................... xxxx passed test CheckSDRefDom

Starting test: CrossRefValidation

......................... xxxx passed test CrossRefValidation


Running enterprise tests on : xxxx.xxx.com

Starting test: LocatorCheck

......................... xxxx.xxx.com passed test LocatorCheck

Starting test: Intersite

......................... xxxx.xxx.com passed test Intersite

[ Voor 0% gewijzigd door TeunBeunHaas op 20-02-2022 13:01 . Reden: Removed more company info ]

[HKLM_]

Dit lijkt mij ook niet goed hoor: SYSVOL has been shared. Failing SYSVOL replication.

Zijn je DC’s momenteel wel in sync? Check dat eens met Repadmin /replsummary en Repadmin /Queue en Repadmin /Showrepl

Waarom is er gelijk gekozen voor een restore van de domain controller? Dat kan zomaar extra ellende meebrengen..

[ Voor 64% gewijzigd door HKLM_ op 20-02-2022 13:05 ]

[TeunBeunHaas]

DC restore, instructed by HQ office

Repadmin /Queue
Queue contains 0 items

Repadmin /replsummary
Shows all DCs, bot 0 failures

Repadmin /Showrepl
All successfull

investigating the SYSVOL issue atm

[HKLM_]

TeunBeunHaas schreef op zondag 20 februari 2022 @ 13:57:
DC restore, instructed by HQ office

Repadmin /Queue
Queue contains 0 items

Repadmin /replsummary
Shows all DCs, bot 0 failures

Repadmin /Showrepl
All successfull

investigating the SYSVOL issue atm

Sorry hoor maar als “ DC restore, instructed by HQ office” de reden is van de restore laat die gasten dan ook het probleem troubleshooten. Het restoren van een DC is wel het laatste wat ik zou doen bij het troubleshooten van dit probleem…

[TeunBeunHaas]

Sorry hoor maar als “ DC restore, instructed by HQ office” de reden is van de restore laat die gasten dan ook het probleem troubleshooten. Het restoren van een DC is wel het laatste wat ik zou doen bij het troubleshooten van dit probleem…

Yea but in the end, my end users suffer. Passing the buck is not always an option, if this wouldnt affect end users, I wouldnt care. But in this case, its a pain for the people in the office.

[TeunBeunHaas]

Buuuuuuuuuuuut, I did keep the "old" VMs from before the restore. I could try copying them back and see if that makes life a bit better.

[HKLM_]

Je weet dat als je dc’s gaat lopen restoren je issues kan krijgen met je domein? Daarom alleen zou ik het al nooit doen…

[MAX3400]

TeunBeunHaas schreef op zondag 20 februari 2022 @ 14:16:
Buuuuuuuuuuuut, I did keep the "old" VMs from before the restore. I could try copying them back and see if that makes life a bit better.

No!

Ik heb geen idee wat jouw kennis is en/of jouw rol in deze; zonder daar tekort aan te doen maar "zomaar" VM's terug gaan zetten van minstens enkele dagen geleden? Nope, absoluuut niet doen!

Ben het eens met @HKLM_ ; er is opdracht gegeven om iets te restoren, bij DC's hoort daar nog wel wat nazorg bij. Dus, ik zou toch eens met HQ gaan bellen en aangeven dat je ondersteuning nodig hebt.

[Brahiewahiewa]

TeunBeunHaas schreef op zondag 20 februari 2022 @ 11:53:
...We can ping on IP internally, but not on name. NSLOOKUP works fine and gives the correct results. Internal ping on host name gives straight away the error “Ping request could not find the host”. This failure comes on both host name and FQDN...

Ik ben dit probleem vaker tegengekomen. Bleek te liggen aan een verkeerde DNS-suffix. Die kun je idd in een group policy distribueren

[DJSmiley]

Dit topic past beter in Serversoftware en Windows Servers

Het is een OS probleem, en geen specifiek netwerkprobleem.

[akimosan]

I would check DNS and DNS settings on both DC's and a client that is suffering from the issues


Start with posting an IPCONFIG /ALL result from both DC's and a workstation/vm
Just information that says "it's configured correctly" doesn't help

DNS queries should be done with with DNS query tools like NSLOOKUP, not PING (at least not exclusively)
If ping name resolving fails it can also be an issue with IP reverse lookup. So first thing to find out if this is a DNS issue or something else..

Also, are DNS records registered for all hosts you are trying to query when you look in the DNS database on the server (probably DNS records are stored in AD)

But let's not get ahead of ourselves and start with the IPCONFIG's I asked first

[ Voor 7% gewijzigd door akimosan op 20-02-2022 22:02 ]

[TeunBeunHaas]

Found a work around, ipconfig /registerdns & rejoining the domain (rejoining alone didnt fix it), seems to be working now again.

Cheers!