Dynamische update

Met dynamische update kunnen DNS-clientcomputers hun bronrecords registreren en bijwerken met een DNS-server wanneer er wijzigingen optreden. Deze functie vermindert de noodzaak voor handmatig beheer van zonerecords, met name voor clients die vaak locaties verplaatsen of wijzigen en DHCP gebruiken om een IP-adres te verkrijgen.

De DNS-client- en serverservices ondersteunen dynamische updates, zoals beschreven in RFC 2136. De DNS Server-service kan dynamische updates per zone in- of uitschakelen. De Windows Server DNS Client-service werkt standaard hostbronrecords (A) dynamisch bij in DNS wanneer deze is geconfigureerd voor TCP/IP. De DNS Server-service is zo geconfigureerd dat alleen beveiligde dynamische updates standaard zijn toegestaan.

Overzicht van protocol

RFC 2136 introduceert de UPDATE berichtindeling, waarmee resourcerecords in een opgegeven zone kunnen worden toegevoegd en verwijderd tijdens het controleren op vereisten. De update is atomisch, wat betekent dat aan alle voorwaarden moet worden voldaan om de update uit te voeren.

De zone-update moet worden doorgevoerd op een primaire DNS-server voor die zone. De secundaire DNS-server stuurt een update door met behulp van de replicatietopologie totdat deze de primaire DNS-server bereikt. Wanneer u een geïntegreerde Active Directory-zone gebruikt, kan een update voor een resourcerecord in een zone worden verzonden naar elke DNS-server die wordt uitgevoerd op een Active Directory-domeincontroller waarvan het gegevensarchief de zone bevat.

Wanneer een zoneoverdrachtsproces wordt gestart, wordt de zone vergrendeld. Deze vergrendeling zorgt ervoor dat een secundaire DNS-server een consistente weergave van de zone ontvangt tijdens het overdragen van de gegevens. Gedurende deze periode kan de zone geen dynamische updates accepteren. Als de zone groot is en vaak is vergrendeld voor overdrachten, kan deze dynamische updateclients verhongeren en instabiliteit van het systeem veroorzaken. Om dit probleem te voorkomen, plaatst de Windows Server DNS Server-service updateverzoeken die binnenkomen tijdens de zoneoverdracht in de wachtrij en verwerkt ze nadat de overdracht is voltooid.

Hoe computers hun DNS-namen bijwerken

Computers die standaard statisch zijn geconfigureerd voor TCP/IP proberen hostbronrecords (A) en pointer (PTR) bronrecords dynamisch te registreren voor IP-adressen die geconfigureerd en gebruikt worden door hun geïnstalleerde netwerkverbindingen. Alle computers registreren records op basis van hun FQDN.

DNS-clients proberen de volgende items niet dynamisch bij te werken:

• Via een VPN-verbinding (Remote Access of Virtual Private Network). Als u deze configuratie wilt wijzigen, kunt u de geavanceerde TCP/IP-instellingen van de specifieke netwerkverbinding wijzigen of het register wijzigen.

• Top-level domein (TLD)-zones. Elke zone met een naam met één label wordt beschouwd als een TLD-zone, bijvoorbeeld , comedu, blank. my-company

Standaard is het primaire DNS-achtervoegselgedeelte van de FQDN van een computer hetzelfde als de naam van het Active Directory-domein waaraan de computer is gekoppeld. Als u verschillende primaire DNS-achtervoegsels wilt toestaan, kan een domeinbeheerder een beperkte lijst met toegestane achtervoegsels maken door het kenmerk msDS-AllowedDNSSuffixes in de domeinobjectcontainer te wijzigen. Een domeinbeheerder kan het kenmerk beheren met BEHULP van ADSI (Active Directory Service Interfaces) of het LIGHTWEIGHT Directory Access Protocol (LDAP). Dynamische updates kunnen om een van de volgende redenen of gebeurtenissen worden verzonden:

• Een IP-adres wordt toegevoegd, verwijderd of gewijzigd in de configuratie van TCP/IP-eigenschappen voor een van de geïnstalleerde netwerkverbindingen.
• Wanneer de computer wordt opgestart.
• Een lidserver wordt gepromoveerd naar een domeincontroller.
• Een IP-adreslease verandert of vernieuwt met de DHCP-server een van de geïnstalleerde netwerkverbindingen, bijvoorbeeld wanneer de computer wordt gestart of als de ipconfig /renew opdracht wordt gebruikt.
• De ipconfig /registerdns opdracht wordt gebruikt om handmatig een vernieuwing van de clientnaamregistratie in DNS af te dwingen.

Wanneer een van de vorige gebeurtenissen een dynamische update activeert, verzendt de DNS-clientservice updates. Deze trigger is zodanig ontworpen dat als er een wijziging in de IP-adresgegevens plaatsvindt, overeenkomende updates in DNS worden uitgevoerd om naam-naar-adrestoewijzingen voor de computer te synchroniseren. De DNS-clientservice voert deze functie uit voor alle netwerkverbindingen die op het systeem worden gebruikt, inclusief verbindingen die niet zijn geconfigureerd voor het gebruik van DHCP.

Bij dit updateproces wordt ervan uitgegaan dat de standaardinstellingen voor installatie van kracht zijn voor servers met Windows Server. Specifieke namen en het updategedrag zijn instelbaar wanneer de geavanceerde TCP/IP-eigenschappen worden geconfigureerd om niet-standaard DNS-instellingen te gebruiken.

Naast de volledige computernaam (of primaire naam) van de computer kunnen verbindingsspecifieke DNS-namen worden geconfigureerd en eventueel worden geregistreerd of bijgewerkt in DNS.

Hoe dynamische update werkt

Dynamische updates worden doorgaans aangevraagd wanneer een DNS-naam of IP-adres op de computer wordt gewijzigd. Stel dat een client met de naam oldhost eerst is geconfigureerd met de volgende namen:

• Computernaam: oldhost
• DNS-domeinnaam: example.contoso.com
• Volledige computernaam: oldhost.example.contoso.com

In dit voorbeeld worden geen verbindingsspecifieke DNS-domeinnamen geconfigureerd voor de computer. Later wordt de naam van de computer gewijzigd van oldhost naar newhost, wat resulteert in de volgende naamwijzigingen op het systeem:

• Computernaam: newhost
• DNS-domeinnaam: example.contoso.com
• Volledige computernaam: newhost.example.contoso.com

Nadat de naamwijziging is toegepast in systeemeigenschappen, wordt u gevraagd de computer opnieuw op te starten. Wanneer windows opnieuw wordt opgestart, voert de DNS-clientservice de volgende volgorde uit om DNS bij te werken:

1. De DNS-clientservice verzendt een SOA-typequery met behulp van de DNS-domeinnaam van de computer.

   De clientcomputer gebruikt de momenteel geconfigureerde FQDN van de computer (zoals newhost.example.contoso.com) als de naam die in deze query is opgegeven.

2. De gezaghebbende DNS-server voor de zone met de client-FQDN reageert op de SOA-query.

   Voor standaard primaire zones is de primaire server (eigenaar) die in het antwoord op de SOA-query wordt geretourneerd, vaststaand en statisch. Deze komt altijd overeen met de exacte DNS-naam zoals deze wordt weergegeven in de SOA-resourcerecord die is opgeslagen met de zone. Als de zone die wordt bijgewerkt in de directory is geïntegreerd, kan elke DNS-server die draait op een domeincontroller voor het Active Directory-domein in de FQDN reageren. Het kan dynamisch zijn eigen naam als de primaire server (eigenaar) van de zone invoegen in de SOA-queryrespons.

3. De DNS-clientservice probeert vervolgens contact op te maken met de primaire DNS-server.

   De client verwerkt het SOA-queryantwoord voor zijn naam om te bepalen welk IP-adres bij de geautoriseerde DNS-server hoort als de primaire server voor het accepteren van zijn naam. Vervolgens wordt de volgende reeks stappen uitgevoerd om contact op te nemen en de primaire server dynamisch bij te werken:

   • Er wordt een dynamische updateaanvraag verzonden naar de primaire server die is bepaald in het ANTWOORD van de SOA-query.
   • Als de update slaagt, wordt er geen verdere actie ondernomen.
   • Als deze update mislukt, verzendt de client vervolgens een NS-type-query voor de zonenaam die is opgegeven in de SOA-record.
   • Wanneer er een antwoord op deze query wordt ontvangen, wordt er een SOA-query verzonden naar de eerste DNS-server die in het antwoord wordt vermeld.

   Nadat de SOA-query is opgelost, verzendt de client een dynamische update naar de server die is opgegeven in de geretourneerde SOA-record.

   • Als de update slaagt, wordt er geen verdere actie ondernomen.
   • Als deze update mislukt, herhaalt de client het SOA-queryproces door een aanvraag te verzenden naar de volgende DNS-server die in het antwoord wordt vermeld.

4. Nadat er verbinding is gemaakt met de primaire DNS-server waarmee de update kan worden uitgevoerd, verzendt de client de updateaanvraag en verwerkt de DNS-server deze.

   De inhoud van de updateaanvraag bevat instructies voor het toevoegen van A-bronrecords (en eventueel PTR)-bronrecords voor newhost.example.contoso.com en verwijderen van dezelfde recordtypen voor oldhost.example.contoso.com, de naam die eerder is geregistreerd.

   De DNS-server controleert ook of updates zijn toegestaan voor de clientaanvraag. Bij primaire standaardzones zijn dynamische updates niet beveiligd, dus elke poging tot clientupdate slaagt. Voor geïntegreerde Active Directory-zones worden updates beveiligd en uitgevoerd met behulp van beveiligingsinstellingen op basis van directory's. Voor meer informatie, zie de sectie Secure dynamic update verderop in dit artikel.

Dynamische updates worden periodiek verzonden of vernieuwd. Standaard verzenden computers elke zeven dagen een vernieuwing. Als de update resulteert in geen wijzigingen in zonegegevens, blijft de zone op de huidige versie en worden er geen wijzigingen geschreven. Updates resulteren in zonewijzigingen of verhoogde zoneoverdrachten alleen wanneer namen of adressen worden gewijzigd.

Namen worden niet verwijderd uit DNS-zones als ze inactief zijn of niet worden bijgewerkt binnen het vernieuwingsinterval (zeven dagen). DNS heeft geen mechanisme voor het vrijgeven of tombstone-namen. DNS-clients proberen echter oude naamrecords te verwijderen wanneer een nieuwe naam wordt toegepast. DNS-clients proberen ook naamrecords bij te werken wanneer een adreswijziging plaatsvindt.

Wanneer de DNS-clientservice A- en PTR-bronrecords registreert voor een computer, wordt een standaardcache van TTL (Time To Live) van 15 minuten gebruikt voor hostrecords. Deze TTL bepaalt hoe lang andere DNS-servers en -clients de records van een computer opslaan wanneer ze worden opgenomen in een queryantwoord.

Levensduur

Wanneer een dynamische updateclient zich in DNS registreert, bevatten de bijbehorende A- en PTR-resourcerecords de TTL (Time to Live). De TTL is standaard ingesteld op 10 minuten voor records die zijn geregistreerd door de Netlogon-service. Voor records die zijn geregistreerd door de DHCP-clientservice, wordt de TTL ingesteld op 15 minuten. Als de DNS Server-service records dynamisch registreert voor zijn eigen zones, is de standaard-TTL 20 minuten. U kunt de standaardinstelling in het register wijzigen. Een kleine waarde zorgt ervoor dat vermeldingen in de cache sneller verlopen, wat het DNS-verkeer laat toenemen, maar het risico dat cache-records verouderd raken, vermindert. Het snel verlopen van vermeldingen is handig voor computers die regelmatig hun DHCP-leases vernieuwen. Lange bewaartijden zijn handig voor computers die hun DHCP-leases niet vaak verlengen.

Naamconflicten oplossen

Wanneer de DNS-clientservice probeert een A-record te registreren, wordt gecontroleerd of de gezaghebbende DNS-zone al een A-record voor dezelfde naam bevat, maar met een ander IP-adres. De DNS-clientservice probeert standaard de bestaande A-record (of records) te vervangen door de nieuwe A-record die het IP-adres van de DNS-client bevat. Als gevolg hiervan kan elke computer in het netwerk de bestaande A-record wijzigen, tenzij beveiligde dynamische update wordt gebruikt. Zones die zijn geconfigureerd voor beveiligde dynamische updates, staan alleen geautoriseerde gebruikers toe om de resourcerecord te wijzigen.

U kunt de standaardinstelling wijzigen zodat de DNS-clientservice het registratieproces beëindigt en de fout in Logboeken registreert in plaats van de bestaande A-record te vervangen. Voor meer informatie, zie de sectie Secure dynamic update verderop in dit artikel.

DNS en DHCP

Windows DNS-clients zijn dynamisch updatebewust en kunnen het dynamische updateproces initiëren. Een DNS-client onderhandelt over het proces van dynamische update met de DHCP-server wanneer de client een IP-adres leaset of de lease verlengt. Deze onderhandeling bepaalt welke computer de A- en PTR-resourcerecords van de client bijwerken. De DNS-client en DHCP-server onderhandelen over wie de records bijwerken. De client en server verzenden dynamische updateaanvragen naar de primaire DNS-servers die gezaghebbend zijn voor de namen die moeten worden bijgewerkt.

De Windows Server DHCP Server-service kan DNS-records bijwerken voor clients die geen ondersteuning bieden voor de FQDN-optie van de DHCP-clientservice. Deze functionaliteit kan worden ingeschakeld op het tabblad DNS van de servereigenschappen voor de DHCP-console. De DHCP-server verkrijgt eerst de naam van verouderde clients van het DHCP REQUEST pakket. Vervolgens wordt de domeinnaam voor dat bereik toegevoegd en worden de A- en PTR-resourcerecords geregistreerd.

In sommige gevallen kunnen verouderde PTR- of A-bronrecords worden weergegeven op DNS-servers wanneer de lease van een DHCP-client verloopt. Wanneer een DNS-client bijvoorbeeld probeert te onderhandelen over een dynamische updateprocedure met een DHCP-server, moet de DNS-client zowel A- als PTR-bronrecords zelf registreren. Als de client later onjuist is verwijderd uit het netwerk, kan de client de registratie van de A- en PTR-resourcerecords niet ongedaan maken en worden ze verouderd.

Als een verouderde A-resourcerecord wordt weergegeven in een zone die alleen beveiligde dynamische updates toestaat, kan er geen andere bronrecord worden geregistreerd voor de naam in die A-resourcerecord. Als u problemen met verouderde PTR- en A-resourcerecords wilt voorkomen, kunt u de functie veroudering en opruiming inschakelen. Zie DNS-veroudering en opruimingsfuncties voor meer informatie over de verouderings- en opruimingsfunctie.

Als u fouttolerantie wilt bieden voor dynamische updates, kunt u Active Directory-integratie overwegen voor zones die dynamische updates van Windows-clients accepteren. Als u de detectie van gezaghebbende DNS-servers wilt versnellen, kunt u elke client configureren met een lijst met voorkeurs- en alternatieve DNS-servers die primair zijn voor die directory-geïntegreerde zone. Als een client de zone niet kan bijwerken met de voorkeurs-DNS-server omdat de DNS-server niet beschikbaar is, kan de client een alternatieve server proberen. Wanneer de voorkeurs-DNS-server beschikbaar wordt, wordt de bijgewerkte, directory-geïntegreerde zone geladen die de update van de client bevat.

Dynamisch updateproces

In deze sectie beschrijven we het dynamische updateproces voor DHCP-clients, statisch geconfigureerde clients, clients voor externe toegang en multihomed clients.

DHCP-clientproces

Om het dynamische updateproces te starten, verzendt de DHCP-client de FQDN-naam naar de DHCP-server in het DHCPREQUEST pakket met behulp van de FQDN-optie van de DHCP-clientservice. De DHCP-server reageert vervolgens op de DHCP-client door een DHCP-bevestigingsbericht (DHCPACK) te verzenden dat de FQDN-optie (optiecode 81) bevat.

De volgende tabel bevat de velden van de FQDN-optie van het DHCPREQUEST pakket.

De voorwaarden waaronder DHCP-clients de FQDN-optie verzenden, zijn afhankelijk van het besturingssysteem waarop de client wordt uitgevoerd en hoe de client wordt geconfigureerd. De acties die door DHCP-servers worden uitgevoerd, zijn ook afhankelijk van het besturingssysteem waarop de server wordt uitgevoerd en hoe de server wordt geconfigureerd.

De Windows DHCP Client-service maakt standaard gebruik van het volgende proces.

1. De Windows DHCP Client-service verzendt de FQDN-optie met het veld Vlaggen ingesteld op 0. Met deze vlag wordt aangevraagd dat de client de A-resourcerecord bijwerkt en de DHCP Server-service de PTR-resourcerecord bijwerkt.

2. De client wacht op een reactie van de DHCP-server. Tenzij de DHCP-server het veld Vlaggen instelt op 3, start de DNS-client vervolgens een update voor de A-resourcerecord.

3. Als de DHCP-server geen ondersteuning biedt of niet is geconfigureerd voor de registratie van de DNS-record, wordt er geen FQDN opgenomen in het antwoord. In dit geval probeert de DNS-client de A- en PTR-resourcerecords te registreren.

Afhankelijk van wat de DHCP-client aanvraagt, kan de DHCP-server verschillende acties uitvoeren.

Als de DHCP-client een DHCPREQUEST bericht zonder de FQDN-optie verzendt, is het gedrag afhankelijk van het type DHCP-server en de configuratie ervan. De DHCP-server werkt beide records bij als u deze configureert voor het bijwerken van records namens DHCP-clients die de FQDN-optie niet ondersteunen.

In de volgende gevallen voert de DHCP-server geen actie uit:

• De DHCP-server biedt geen ondersteuning voor dynamische updates.

• De DHCP-server is geconfigureerd om geen dynamische updates uit te voeren voor clients die de FQDN-optie niet ondersteunen.

• De DHCP-server is geconfigureerd om DNS-bronrecords niet te registreren.

Als de Windows DHCP-client vraagt dat de server de PTR-resourcerecord bijwerken, maar niet de A-resourcerecord, is het gedrag afhankelijk van het type DHCP-server en de configuratie ervan.

De server kan een van de volgende acties uitvoeren:

• Als de Windows DHCP-server is geconfigureerd om geen dynamische updates uit te voeren, bevat deze niet de FQDN-optie in het antwoord. Er wordt ook geen bronrecord bijgewerkt. In dit geval probeert de DNS-client zowel de A- als PTR-resourcerecords bij te werken als deze daartoe in staat is.

• Als de Windows DHCP-server is geconfigureerd om bij te werken op basis van de aanvraag van de DHCP-client, probeert de server de PTR-resourcerecord bij te werken. De DHCP-server verzendt een DHCPACK bericht naar de DHCP-client. Dit bericht bevat de FQDN-optie met het veld Vlaggen ingesteld op 0. Het DHCPACK bericht bevestigt dat de DHCP-server de PTR-record bijwerken. De DNS-client probeert vervolgens de A-resourcerecord bij te werken, als deze geschikt is.

• Als de DHCP-server is geconfigureerd voor het altijd bijwerken van A- en PTR beide records, probeert de DHCP-server beide bronrecords bij te werken. Het DHCP-serverbericht DHCPACK naar de DHCP-client bevat de FQDN-optie met het veld Vlaggen ingesteld op 3, waarbij de DHCP-client wordt geïnformeerd dat de DHCP-server A- en PTR-records bijwerkt. In dit geval probeert de DNS-client geen van beide resourcerecords bij te werken.

Statisch geconfigureerd en extern toegangsclientproces

Statisch geconfigureerde clients en clients voor externe toegang zijn niet afhankelijk van de DHCP-server voor DNS-registratie. Statisch geconfigureerde clients werken hun A- en PTR-resourcerecords dynamisch bij telkens wanneer ze worden gestart. Clients worden ook elke 24 uur bijgewerkt om records in de DNS-database te vernieuwen.

Clients voor externe toegang kunnen A- en PTR-resourcerecords dynamisch bijwerken wanneer er een inbelverbinding wordt gemaakt. Ze kunnen ook proberen om de A- en PTR-resourcerecords in te trekken of de registratie ervan ongedaan te maken wanneer de gebruiker de verbinding expliciet sluit. Computers met Windows Server met een netwerkverbinding voor externe toegang proberen de A- en PTR-records dynamisch te registreren voor het IP-adres van deze verbinding. De DNS-clientservice op de Windows-client probeert standaard geen dynamische update uit te voeren via een externe toegang of VPN-verbinding. Als u deze configuratie wilt wijzigen, kunt u de geavanceerde TCP/IP-instellingen van de specifieke netwerkverbinding wijzigen of het register wijzigen.

Als een rastoegangsclient in alle besturingssystemen geen geslaagd antwoord ontvangt van de poging om een DNS-resourcerecord te deregistereren of om een andere reden mislukt om de registratie van een resourcerecord binnen vier seconden ongedaan te maken, sluit de DNS-client de verbinding. In dergelijke gevallen kan de DNS-database een verlopen record bevatten.

Als de RAS-client de registratie van een DNS-resourcerecord niet kan ongedaan maken, wordt er een bericht toegevoegd aan het gebeurtenislogboek, dat u kunt weergeven met behulp van Logboeken. De RAS-client verwijdert nooit verouderde records, maar de RAS-server probeert de registratie van de PTR-resourcerecord ongedaan te maken wanneer de verbinding met de client wordt verbroken.

De Windows DNS Client-service probeert standaard geen A- en PTR-records automatisch bij te werken voor inbelverbindingen.

Multihomed cliëntproces

Als een dynamische updateclient multihomed is, wat betekent dat de client meer dan één netwerkverbinding en het bijbehorende IP-adres heeft, worden alle IP-adressen voor elke netwerkverbinding geregistreerd. Als u niet wilt dat deze IP-adressen worden geregistreerd, kunt u de netwerkverbinding configureren om GEEN IP-adressen te registreren.

De client voor dynamische updates registreert niet alle IP-adressen bij de DNS-servers in alle naamruimten waarmee de computer is verbonden. Een multihomed computer, bijvoorbeeld, client1.example.contoso.comis verbonden met zowel internet als het bedrijfsintranet. De client is verbonden met het intranet door adapter A, een DHCP-adapter met het IP-adres 172.16.8.7. De client is ook verbonden met internet via adapter B, een adapter voor externe toegang met het IP-adres 10.3.3.9. De client lost intranetnamen op met behulp van een naamserver op het intranet en lost internetnamen op met behulp van een naamserver op internet.

Dynamische update beveiligen

Dns-updatebeveiliging is alleen beschikbaar voor zones die zijn geïntegreerd in Active Directory. Wanneer u een zone integreert in Active Directory, zijn toegangsbeheerlijsten (ACL) beschikbaar in de DNS-console om gebruikers en groepen toe te voegen aan of te verwijderen uit de ACL voor een opgegeven zone of resourcerecord. ACL's zijn alleen bedoeld voor toegangscontrole bij DNS-beheer en hebben geen invloed op DNS-queryomzetting.

Dynamische updatebeveiliging voor DNS-servers en -clients wordt standaard als volgt verwerkt:

• DNS-clients proberen eerst onbeveiligde dynamische update te gebruiken. Als een niet-beveiligde update wordt geweigerd, proberen clients beveiligde updates te gebruiken.

  Met het standaardupdatebeleid kunnen clients proberen een eerder geregistreerde resourcerecord te overschrijven, tenzij geblokkeerd.

• Nadat een zone is geïntegreerd met Active Directory, worden DNS-servers waarop Windows Server wordt uitgevoerd, standaard ingesteld op het toestaan van alleen beveiligde dynamische updates.

  Wanneer u zoneopslag op basis van bestanden gebruikt, is de standaardinstelling voor de DNS Server-service om dynamische updates voor de zones niet toe te staan. Voor zones die zijn geïntegreerd in mappen of standaardopslag op basis van bestanden gebruiken, kunt u de zone wijzigen om alle dynamische updates toe te staan. Met deze instelling kunnen alle updates worden geaccepteerd.

Dynamische update is een aanvulling op de DNS-standaardspecificatie, gedefinieerd in RFC 2136.

De dynamische registratie van DNS-resourcerecords kan worden beperkt met het gebruik van registervermeldingen.

Hoe beveiligde dynamische update werkt

Het beveiligde dynamische updateproces wordt als volgt beschreven:

1. Als u een beveiligde dynamische update wilt initiëren, initieert de DNS-client eerst het onderhandelingsproces voor beveiligingscontext, waarbij de tokens worden doorgegeven tussen client en server met behulp van TKEY-resourcerecords. Aan het einde van het onderhandelingsproces wordt de beveiligingscontext tot stand gebracht.

2. De DNS-client verzendt de aanvraag voor dynamische updates naar de DNS-server. Deze aanvraag bevat resourcerecords voor het toevoegen, verwijderen of wijzigen van gegevens.

   1. De aanvraag wordt ondertekend met behulp van de eerder tot stand gebrachte beveiligingscontext.

   2. De handtekening wordt doorgegeven in de TSIG-resourcerecord, die is opgenomen in het pakket voor dynamische updates.

3. De server probeert Active Directory bij te werken met de referenties van de client en verzendt het resultaat van de update naar de client. Deze resultaten worden ook ondertekend met behulp van de beveiligingscontext en de handtekening die is doorgegeven in de TSIG-resourcerecord die in het antwoord is opgenomen.

Dynamisch updateproces beveiligen

Het beveiligde dynamische updateproces wordt als volgt beschreven:

1. De DNS-client voert een query uit op de dns-voorkeursserver om te bepalen welke DNS-server gezaghebbend is voor de domeinnaam die wordt bijgewerkt. De voorkeurs-DNS-server reageert met de naam van de zone en de primaire DNS-server die gezaghebbend is voor de zone.

2. De DNS-client probeert een standaard dynamische update uit te voeren en als de zone zodanig is geconfigureerd dat alleen beveiligde dynamische updates (de standaardconfiguratie voor geïntegreerde Active Directory-zones) zijn toegestaan, weigert de DNS-server de onbeveiligde update. Als de zone is geconfigureerd voor een standaard dynamische update in plaats van een beveiligde dynamische update, accepteert de DNS-server de poging van de DNS-client om bronrecords in die zone toe te voegen, te verwijderen of te wijzigen.

3. De DNS-client en DNS-server beginnen met TKEY-onderhandeling.

   1. De DNS-client en de DNS-server onderhandelen over een onderliggend beveiligingsmechanisme. Windows Dynamic Update-clients en DNS-servers kunnen alleen het Kerberos-protocol gebruiken.

   2. Met behulp van het beveiligingsmechanisme verifiëren de DNS-client en DE DNS-server hun respectieve identiteiten en stellen ze de beveiligingscontext vast.

4. De DNS-client verzendt de aanvraag voor dynamische updates naar de DNS-server, ondertekend met behulp van de tot stand gebrachte beveiligingscontext. De handtekening wordt opgenomen in het handtekeningveld van de TSIG-resourcerecord die is opgenomen in het aanvraagpakket voor dynamische updates. De DNS-server controleert de oorsprong van het dynamische updatepakket met behulp van de beveiligingscontext en de TSIG-handtekening.

5. De DNS-server probeert resourcerecords toe te voegen, te verwijderen of te wijzigen in Active Directory. De update is afhankelijk van of de DNS-client over de juiste machtigingen beschikt en of aan de vereisten wordt voldaan.

6. De DNS-server verzendt een antwoord naar de DNS-client waarin wordt aangegeven of de update kon worden uitgevoerd, ondertekend met behulp van de tot stand gebrachte beveiligingscontext. De handtekening wordt opgenomen in het handtekeningveld van de TSIG-resourcerecord die is opgenomen in het antwoordpakket voor dynamische updates. Als de DNS-client een vervalst antwoord ontvangt, wordt het genegeerd en wordt gewacht op een ondertekend antwoord.

Beveiliging voor DHCP-clients die de FQDN-optie niet ondersteunen

Windows DHCP-clients die geen ondersteuning bieden voor de FQDN-optie (optie 81) zijn niet geschikt voor dynamische updates. Als u wilt dat de A- en PTR-bronrecords voor deze clients dynamisch zijn geregistreerd in DNS, moet u de DHCP-server configureren om namens hen dynamische updates uit te voeren.

Als de DHCP-server beveiligde dynamische updates uitvoert namens DHCP-clients die de FQDN-optie niet ondersteunen, is extra configuratie vereist om een machtigingsprobleem te voorkomen. Wanneer een DHCP-server een beveiligde dynamische update uitvoert op een naam, wordt deze de eigenaar van die naam. Alleen die DHCP-server kan elke record voor die naam bijwerken.

Stel dat de DHCP-server DHCP1 een object voor de naam host1.example.com heeft gemaakt en vervolgens niet meer reageert, en dat later de back-up dhcp-server DHCP2 een record probeerde bij te werken voor dezelfde naam, host1.example.com. In dit geval kan DHCP2 de naam niet bijwerken omdat deze niet de eigenaar is van de naam.

Gebruik de ingebouwde beveiligingsgroep DnsUpdateProxy om dit probleem te voorkomen. Als u alle DHCP-servers toevoegt als leden van de DnsUpdateProxy-groep, kan een andere server de records van één server bijwerken als de eerste server mislukt. Omdat alle objecten die zijn gemaakt door de leden van de groep DnsUpdateProxy niet zijn beveiligd, wordt de eerste gebruiker die de set records wijzigt die zijn gekoppeld aan een DNS-naam, de eigenaar. Wanneer verouderde clients worden bijgewerkt, kunnen ze eigenaar worden van hun naamrecords op de DNS-server. Als elke DHCP-server die bronrecords registreert voor oudere clients lid is van de DnsUpdateProxy-groep, treden de eerder besproken problemen niet op.

Records beveiligen met behulp van de groep DnsUpdateProxy

Wanneer de DHCP-server lid is van de DnsUpdateProxy-groep, worden de DNS-domeinnamen die worden geregistreerd niet beveiligd. Gebruik deze groep daarom niet in een geïntegreerde Active Directory-zone die alleen beveiligde dynamische updates toestaat zonder dat u meer stappen hoeft uit te voeren om records die door leden van de groep zijn gemaakt, te beveiligen.

Om te beschermen tegen niet-beveiligde records, of om leden van de DnsUpdateProxy-groep in staat te stellen records te registreren in zones die alleen beveiligde dynamische updates toestaan, maakt u een speciale gebruikersaccount aan. Configureer DHCP-servers met behulp van de referenties van dit gebruikersaccount om dynamische DNS-updates uit te voeren. Meerdere DHCP-servers kunnen de referenties van één toegewezen gebruikersaccount gebruiken.

Het speciale gebruikersaccount is een standaardgebruikersaccount dat alleen door DHCP-servers wordt gebruikt om referenties te leveren voor de registratie van dynamische DNS-updates. Elke DHCP-server levert deze referenties bij het registreren van namen namens DHCP-clients met behulp van dynamische DNS-updates. Het toegewezen gebruikersaccount wordt gemaakt in hetzelfde forest waarin de primaire DNS-server voor de zone die moet worden bijgewerkt zich bevindt. Het toegewezen gebruikersaccount kan zich ook in een ander forest bevinden, zolang het forest waarin het zich bevindt een forestvertrouwensrelatie tot stand is gebracht met het forest dat de primaire DNS-server bevat, zodat de zone kan worden bijgewerkt.

Wanneer deze is geïnstalleerd op een domeincontroller, neemt de DHCP Server-service de beveiligingsmachtigingen van de domeincontroller over. Dit betekent dat het de bevoegdheid heeft om een DNS-record bij te werken of te verwijderen die is geregistreerd in een beveiligde active Directory-geïntegreerde zone. Andere computers met Windows Server, zoals domeincontrollers, registreren deze records veilig. Wanneer deze is geïnstalleerd op een domeincontroller, configureert u de DHCP-server met de referenties van het toegewezen gebruikersaccount om te voorkomen dat de server de bevoegdheden van de domeincontroller overdragt en mogelijk misbruikt.

Configureer een toegewezen gebruikersaccount en configureer de DHCP Server-service met de accountreferenties onder de volgende omstandigheden:

• Een domeincontroller is geconfigureerd om te functioneren als een DHCP-server.
• De DHCP-server is geconfigureerd voor het uitvoeren van dynamische DNS-updates namens DHCP-clients.
• De DHCP-server werkt DNS-zones bij die zijn geconfigureerd om alleen beveiligde dynamische updates toe te staan.

Nadat u een toegewezen gebruikersaccount hebt gemaakt, kunt u DHCP-servers configureren met de referenties van het gebruikersaccount met behulp van de DHCP-console of met behulp van de opdracht netsh dhcp server set dnscredentials.