msdcs delegation mist NS records

[mookie]

Ons domein is opgezet met server 2003 SP1 als eerste server, dus geen upgrade van een 2000 omgeving. Derhalve is er een aparte zone voor zowel domein.local als _msdcs.domein.local. Maar in de domein.local zone is wel een stubzone voor _msdcs aangemaakt, zoals gebruikelijk. (Of is het een delegation, weet het niet zeker, maar goed, dat grijze dingetje)

Nu zijn we net die server aan het opdoeken omdat hij dus nog 2003 draait. Het viel mij op dat de stubzone/delegation enkel een NS record bevat voor de eerste server die ooit is opgezet.

Er zijn meerdere DC's, verspreid over meerdere fysieke locaties. Er zijn ook nog wat andere windows domeinen die een trust hebben met dit domein. De DC's van die andere domeinen halen een kopie van domein.local binnen als secondary zone. In die kopie vinden zij een delegation (danwel stubzone, weet niet precies welke van de twee maar goed) _msdcs.domein.local met een enkel NS record, namelijk dat van deze server in kwestie, welke de server is waarop het domein is aangemaakt.

1. De eerste DC (2K3) waar het domein op is aangemaakt staat in nederland en heet DC1-NL.domein.local
2. De tweede DC (2K3 staat ook in nederland en heet DC2-NL.domein.local
3. De derde DC (2K12) die bovenstaande overbodig moet maken staat ook in NL en heet DC3-NL.domein.local
4. Dan staat er nog een DC in Italie (2K8r2) en die heet DC1-IT.domein.local

Op elke server is de DNS situatie als volgt.

• domein.local DNS zone, met daarin NS en A records van alle DC's en het SOA record bevat de correcte server. Op DC1-NL is het soa record dus netjes DC1-NL en op DC3-NL is het SOA record netjes DC3-NL
• de delegation/stubzone _msdcs.domein.local bevat enkel een NS record en dat is DC1-NL op elke server
• de _msdcs.domein.local zone op iedere ziet er prima uit. NS records voor iedere DC, CNAME records voor de GUIDS van de DC's en de SOA is op iedere server de DC zelf zoals bij de domein.local zone.

Het "andere" domein in Italie heeft een DC, laten we zeggen ANDEREDC1-IT uit anderdomein.local
ANDEREDC1-IT.anderdomein.local heeft een secondary zone genaamd domain.local die hij netjes kopieert van DC1-IT.domein.local
Vervolgens zoekt hij een DC voor domein.local op uit de _msdcs zone en komt dan die delegation/stubzone tegen en daarin staat dan een NS record van DC1-NL.domein.local en daarna gaat hij dus querien over het WAN op die ene DC in Nederland.

Wat heb ik al gedaan?

• Gekeken in eventlog maar daar staan geen errors in. DNS event Logging staat gewoon op "all events" en werkt wel want ik zie wel de succesvolle zone transfers voor de secondary zones.
• Gekeken met adsiedit of ik de zone niet dubbel in de AD had staan, b.v. eenmaal in forestdnszone en eenmaal in domeindnszones maar dat is niet het geval.
• updates staan op only secure updates en alles werkt dan ook prima, clients/servers registreren zichzelf netjes.
• dcdiag draaien en die vind geen fouten.
• uiteraard veel google maar kom enkel mensen tegen die problemen hebben met de _msdcs.domein.local zone en niet die problemen hebben met de delegation/stubzone onder domein.local

Ik heb geen vergelijkings materiaal. Alle andere omgevingen zijn een upgrade vanuit een 2000 omgeving danwel bestaan uit slechts 1 DC.
Kan iemand eens kijken of je in die delegation/stubzone wel meerdere NS records hebt staan?
Ik neem zelf een beetje aan dat daarin gewoon alle DNS servers vermeld dienen te worden...

[Semt-x]

Je kan beter meerdere name servers toevoegen in dat record.
Het is bijzonder dat dit record bij jullie nog een actieve rol speelt. Normaliter doet dit record niet meer te zake.
Als je de gelegenheid hebt kun je een keer een test uitvoeren, door het IP adres in dat delegation record van die enige DC te vervangen door een niet bestaand IP adres.
Dan zal je zien dat clients uit het .it domein geen resources meer kunnen benaderen van het .nl domein. Andersom blijft het wel werken.

De definitieve oplossing zit in het herstructureren van je name resolving, zodat dit _msdcs delegation record geen rol meer speelt.
Het _msdcs delegation record is het gevolg van schaalbaarheidsbeperkingen die AD had toen _msdcs record onderdeel was van de gewone zone.

[mookie]

Ik denk dat het bij iedereen wel een actieve rol speelt. Lijkt mij gewoon standaard altijd aanwezig. Ik snap dat de "nieuwe" _msdcs.domein.local zone standaard forestwide repliceert, en dat daardoor alle DNS servers beschikken over de gehele _msdcs.domein.local zone. Omdat ze die zone al lokaal hebben hoeven ze niet terug te vallen op het "glue record" uit de delegation.

Dit gaat echter alleen op als je andere domeinen in hetzelfde forest zitten. Als je gewoon een two way trust hebt tussen windows domeinen die niet in hetzelfde forest zitten dan zullen de domein controllers toch af en toe van elkaar moeten opzoeken welke DC in welke site beschikbaar is. Aangezien ze alleen de normale domein.local zone als secondary hebben en daarin die delegation vinden komen ze voor _msdcs queries toch weer uit bij die ene server die in die delegation vermeld staat.

En als ik de domein.local zone niet als secondary beschikbaar maak, maar ik maak een conditional forwarder aan naar DC1-IT.domein.local blijft het originele probleem bestaan, namelijk dat ze enkel het delegation record zien en daarna zich weer richten naar die ene enkele server die daarin vermeld staat.

Ik heb zojuist een schoon domein opgezet in een hyper-v testomgeving met server 2012. Eerst de eerste server "server1.testdomein.test" met daarop AD DS en DNS en domein aangemaakt, meteen server 2012 native etc etc alles standaard en dan krijg je dezelfde situatie als wanneer je dat vanaf server 2003 doet, namelijk 2 zones (testdomein.test en _msdcs.testdomein.test) en onder testdomein.test zit een delegation naar _msdcs.testdomein.test. Daarna heb ik een 2de server toegevoegd, ook DC gemaakt en ik zie dat die 2de server zich netjes registreert in de "gewone" testdomein.test zone met NS en A records, en dat hij zichzelf ook netjes registreerd in de _msdcs.testdomein.test zone. Echter, de delegation in testdomein.test blijft een enkel IP adres bevatten, dus enkel server1.testdomein.test.

Dus, terugkomend op de initiële conclusie van mij: de delegation bevat bij mij maar 1 nameserver entry, namelijk de eerste server waarop het domein in eerste instantie is aangemaakt. Dit gebeurt mij nu wederom nu ik een schone installatie in een apart domein heb gedaan. Wellicht is dat wel standaard en hoort het zo, maar dat kan ik dus nergens terugvinden (b.v. een Microsoft artikeltje ergens)

Ik zie het vaker terug op websites, bijvoorbeeld hier
Eerst zie je 2 plaatjes van de windows 2000 situatie, daarna zie je de w2k3 situatie.

En daarom wil ik toch nogmaals vragen: wie heeft er toegang tot een domein met minimaal 2 DC's en kan eens kijken wat hij in zijn delegation heeft staan. Slechts 1 NS record of meerdere NS records, en kun je met zekerheid zeggen, mits je er meerdere hebt, of dat die handmatig zijn toegevoegd of er automatisch in terecht zijn gekomen.

[Semt-x]

"maar ik maak een conditional forwarder aan naar DC1-IT.domein.local blijft het originele probleem bestaan"
Dat is in mijn ogen een verkeerde aanname. Een conditional forwarder voor domein.local zal alle verzoeken voor domein.local forwarden naar het opgegeven IP adres. ook de _msdcs.domein.local verzoeken.
Als de ontvangende DNS server een verzoek krijgt, zal deze direct de _msdcs zone aanspreken en het _msdcs delegation record overslaan. Omdat de _msdcs.domein.local zone “specifieker” is.

Ik zou de naamresolving anders inrichten; afstappen van de secondary zone replicatie en overstappen op conditional forwarders. Dan ben je niet langer afhankelijk van dat delegation record en niet van de storingsgevoeligheid van DNS replicatie. Dan doet je originele vraag ook niet langer ter zaken, dat delegation record wordt niet geraadpleegd.

Zone replicatie stamt uit de tijd Win2000, net als het geïntegreerde _msdcs record “map” in de domein zone. Met Windows 2003 werd conditional forwarder geïntroduceerd, wat de configuratie vereenvoudigd en het een stuk flexibeler maakt.

Ik zie bij veel klanten dat zone replicatie nog in gebruik is, dat vervang ik door conditional forwarders tijdens het project waar ze me voor inhuren. (dit soort wijzigingen maken onderdeel uit van de opdracht)

[Dennism]

Bij mij staan er 3 in de properties van de delegation, te weten alle 3 de DC's in het domain. Ik durf het niet met zekerheid te zeggen, maar ik verwacht dat ze er automatisch in terecht zijn gekomen. Daar 1 van deze DC's door mij uitgerold is en ik dit record niet heb toegevoegd, en sinds ik het beheer doe is er ook geen andere beheerder actief geweest binnen de organisatie.

[ Voor 17% gewijzigd door Dennism op 04-06-2015 10:48 ]

[Razwer]

Semt-x schreef op donderdag 04 juni 2015 @ 10:45:
Ik zou de naamresolving anders inrichten; afstappen van de secondary zone replicatie en overstappen op conditional forwarders. Dan ben je niet langer afhankelijk van dat delegation record en niet van de storingsgevoeligheid van DNS replicatie. Dan doet je originele vraag ook niet langer ter zaken, dat delegation record wordt niet geraadpleegd.

Zone replicatie stamt uit de tijd Win2000, net als het geïntegreerde _msdcs record “map” in de domein zone. Met Windows 2003 werd conditional forwarder geïntroduceerd, wat de configuratie vereenvoudigd en het een stuk flexibeler maakt.

Ik zie bij veel klanten dat zone replicatie nog in gebruik is, dat vervang ik door conditional forwarders tijdens het project waar ze me voor inhuren. (dit soort wijzigingen maken onderdeel uit van de opdracht)

Zone replication is soms nog wel voordelig wanneer WAN verbindingen niet super stabiel zijn. Afhankelijk van de inrichting kan het dus nog de betere oplossing zijn, maar verder ben ik het volledig eens met jouw verhaal gezien 99 uit de 100 gevallen dat wel van toepassing is.