Netwerkcrash in Oss door DHCP of DNS

Hoe herstellen we zonder nieuwe schade?

Een website die dankzij browsercache opent, bewijst niet dat de DNS-server of het juiste interne naamroute werkelijk is hersteld. DHCP-nodes en rollen, scopes en bezetting, reserveringen en opties, relay en firewallpad, leases en dynamische DNS, resolvers, forwarders, zones, serienummers, TTL, negatieve cache en private namen blijven gekoppeld.

U ziet of gecontroleerde overname, journalherstel, configuratieterugzetting of zonesynchronisatie nodig is en welke noodinstelling moet verdwijnen. We onderzoeken en controleren onder meer DHCP-failover en scopes, leases en conflicten, relay, DNS-resolvers en forwarders, gezaghebbende zones en replica’s, positieve en negatieve antwoorden, private DNS, tijd, serviceaccounts en monitoring.

Tijdelijke statische adressen, noodresolver en testrecords worden verwijderd. Lease-, zone- en replicatiestatus gaan met de gekozen herstelvolgorde naar beheer. Vanuit twee relevante netwerkzones vragen testclients een nieuw adres aan, vernieuwen dat adres en controleren reserveringen en opties.

Hoe controleren we dat het netwerk terug is?

Daarna testen we een bestaande naam, een bewust niet-bestaande naam, een gewijzigde record en waar gebruikt een private cloudnaam. De test gebruikt geen oude lokale cache. Leases, dynamische DNS en zones worden daarna op dubbele of achtergebleven gegevens gecontroleerd. We herhalen de route na een serverwissel of serviceherstart.

Tot slot moet een herkenbare bedrijfsapplicatie via de normale naam bruikbaar zijn en moet monitoring de actieve serverrol correct tonen. Een noodadres of alternatieve resolver blijft alleen tijdelijk voor een begrensde groep en krijgt direct een eigenaar en verwijdermoment.