Dynamisk uppdatering

Med dynamisk uppdatering kan DNS-klientdatorer registrera och uppdatera sina resursposter med en DNS-server när ändringar sker. Den här funktionen minskar behovet av manuell administration av zonposter, särskilt för klienter som ofta flyttar eller ändrar platser och använder DHCP för att hämta en IP-adress.

DNS-klient- och servertjänsterna stöder dynamisk uppdatering enligt beskrivningen i RFC 2136. DNS Server-tjänsten kan aktivera eller inaktivera dynamiska uppdateringar per zon. Som standard uppdaterar Windows Server DNS-klienttjänsten värdresursposterna (A) dynamiskt i DNS när de konfigureras för TCP/IP. DNS Server-tjänsten är konfigurerad för att endast tillåta säkra dynamiska uppdateringar som standard.

Protokollöversikt

RFC 2136 introducerar UPDATE meddelandeformatet, vilket gör det möjligt att lägga till och ta bort resursposter i en angiven zon vid kontroll av förutsättningar. Uppdateringen är atomisk, vilket innebär att alla villkor måste uppfyllas för att uppdateringen ska ske.

Zonuppdateringen måste utföras på en primär DNS-server för den zonen. Den sekundära DNS-servern vidarebefordrar en uppdatering med replikeringstopologin tills den når den primära DNS-servern. När du använder en Active Directory-integrerad zon kan en uppdatering för en resurspost i en zon skickas till alla DNS-servrar som körs på en Active Directory-domänkontrollant vars datalager innehåller zonen.

När en zonöverföringsprocess startar låser den zonen. Det här låset säkerställer att en sekundär DNS-server får en konsekvent vy över zonen när data överförs. Under den här tiden kan zonen inte acceptera dynamiska uppdateringar. Om zonen är stor och ofta låst för överföringar kan den svälta dynamiska uppdateringsklienter och orsaka systeminstabilitet. För att undvika det här problemet köar DNS-servrarna i Windows Server-tjänsten uppdateringsbegäranden som tas emot under zonöverföringen och bearbetar dem när överföringen är klar.

Så här uppdaterar datorer sina DNS-namn

Som standard försöker datorer som är statiskt konfigurerade för TCP/IP att dynamiskt registrera värdresursposter (A) och pekare (PTR) för IP-adresser som konfigurerats och används av deras installerade nätverksanslutningar. Alla datorer registrerar poster baserat på deras fullständiga domännamn.

DNS-klienter försöker inte uppdatera följande objekt dynamiskt:

• Via en anslutning till fjärråtkomst eller virtuellt privat nätverk (VPN). Om du vill ändra den här konfigurationen kan du ändra de avancerade TCP/IP-inställningarna för den specifika nätverksanslutningen eller ändra registret.

• Toppnivådomänzoner (TLD). Alla zoner med ett enkelnamn betraktas som en TLD-zon, till exempel com, edu, blank, my-company.

Som standard är den primära DNS-suffixdelen av en dators fullständiga domännamn detsamma som namnet på den Active Directory-domän som datorn är ansluten till. Om du vill tillåta olika primära DNS-suffix kan en domänadministratör skapa en begränsad lista över tillåtna suffix genom att ändra attributet msDS-AllowedDNSSuffixes i domänobjektcontainern. En domänadministratör kan hantera attributet med hjälp av Active Directory Service Interfaces (ADSI) eller Lightweight Directory Access Protocol (LDAP). Dynamiska uppdateringar kan skickas av någon av följande orsaker eller händelser:

• En IP-adress läggs till, tas bort eller ändras i konfigurationen för TCP/IP-egenskaper för någon av de installerade nätverksanslutningarna.
• Vid start, när datorn är aktiverad.
• En medlemsserver befordras till en domänkontrollant.
• Ett IP-adresslån ändras eller förnyas med DHCP-servern någon av de installerade nätverksanslutningarna, till exempel när datorn startas eller om ipconfig /renew kommandot används.
• Kommandot ipconfig /registerdns används för att manuellt framtvinga en uppdatering av klientnamnsregistreringen i DNS.

Important

Om du använder ipconfig /registerdnsförsöker DNS-klienttjänsten registrera sin DNS-post direkt och kringgår DHCP-servern. Den här registreringen sker även om DHCP-servern är konfigurerad för att Alltid dynamiskt uppdatera DNS A- och PTR-poster. Om klienten inte har behörighet att uppdatera resursposten misslyckas registreringen tyst. Om DNS-klienten har den här behörigheten uppdateras resursposten. Behörigheter kan återställas så att DHCP-servern inte längre kan utföra framtida uppdateringar på resursposten.
Den rekommenderade metoden för att uppdatera DNS-registrering för DHCP-klienter som kör Windows är att använda ipconfig /renew. Använd inte ipconfig /registerdns.

När en av de tidigare händelserna utlöser en dynamisk uppdatering skickar DNS-klienttjänsten uppdateringar. Den här utlösaren är utformad så att om en ändring av IP-adressinformationen sker utförs motsvarande uppdateringar i DNS för att synkronisera namn-till-adress-mappningar för datorn. DNS-klienttjänsten utför den här funktionen för alla nätverksanslutningar som används i systemet, inklusive anslutningar som inte har konfigurerats för att använda DHCP.

Den här uppdateringsprocessen förutsätter att standardinställningarna för installation gäller för servrar som kör Windows Server. Specifika namn och uppdateringsbeteende är justerbart där avancerade TCP/IP-egenskaper konfigureras för att använda andra än standardinställningar för DNS.

Förutom datorns fullständiga datornamn (eller primära namn) kan anslutningsspecifika DNS-namn konfigureras och eventuellt registreras eller uppdateras i DNS.

Så här fungerar dynamisk uppdatering

Dynamiska uppdateringar begärs vanligtvis när antingen ett DNS-namn eller en IP-adress ändras på datorn. Anta till exempel att en klient med namnet oldhost först konfigureras med följande namn:

• Datornamn: oldhost
• DNS-domännamn: example.contoso.com
• Fullständigt datornamn: oldhost.example.contoso.com

I det här exemplet konfigureras inga anslutningsspecifika DNS-domännamn för datorn. Senare byter datorn namn från oldhost till newhost, vilket resulterar i följande namnändringar i systemet:

• Datornamn: newhost
• DNS-domännamn: example.contoso.com
• Fullständigt datornamn: newhost.example.contoso.com

När namnändringen har tillämpats i Systemegenskaper uppmanas du att starta om datorn. När datorn startar om Windows utför DNS-klienttjänsten följande sekvens för att uppdatera DNS:

1. DNS-klienttjänsten skickar en SOA-typfråga med hjälp av datorns DNS-domännamn.

   Klientdatorn använder det för närvarande konfigurerade fullständiga domännamnet för datorn (till exempel newhost.example.contoso.com) som det namn som anges i den här frågan.

2. Den auktoritativa DNS-servern för zonen som innehåller klientens FQDN svarar på frågan av SOA-typ.

   För primära standardzoner är den primära servern (ägaren) som returneras i SOA-frågesvaret fast och statisk. Det matchar alltid det exakta DNS-namnet som det visas i SOA-resursposten som lagras med zonen. Om zonen som uppdateras är katalogintegrerad kan alla DNS-servrar som körs på en domänkontrollant för Active Directory-domänen i FQDN svara. Den kan dynamiskt infoga sitt eget namn som primär server (ägare) för zonen i SOA-frågesvaret.

3. DNS-klienttjänsten försöker sedan kontakta den primära DNS-servern.

   Klienten bearbetar SOA-frågesvaret för sitt namn för att fastställa IP-adressen för DEN DNS-server som är auktoriserad som primär server för att acceptera dess namn. Sedan fortsätter den att utföra följande sekvens med steg efter behov för att kontakta och dynamiskt uppdatera sin primära server:

   • Den skickar en begäran om dynamisk uppdatering till den primära servern som fastställs i SOA-frågesvaret.
   • Om uppdateringen lyckas vidtas ingen ytterligare åtgärd.
   • Om uppdateringen misslyckas skickar klienten sedan en NS-typfråga för det zonnamn som anges i SOA-posten.
   • När den får ett svar på den här frågan skickar den en SOA-fråga till den första DNS-servern som anges i svaret.

   När SOA-frågan har lösts skickar klienten en dynamisk uppdatering till servern som anges i den returnerade SOA-posten.

   • Om uppdateringen lyckas vidtas ingen ytterligare åtgärd.
   • Om uppdateringen misslyckas upprepar klienten SOA-frågeprocessen genom att skicka en begäran till nästa DNS-server som anges i svaret.

4. När den primära DNS-servern som kan utföra uppdateringen har kontaktats skickar klienten uppdateringsbegäran och DNS-servern bearbetar den.

   Innehållet i uppdateringsbegäran innehåller instruktioner för att lägga till A-resursposter (och eventuellt PTR) för newhost.example.contoso.com och ta bort samma posttyper för oldhost.example.contoso.com, namnet som tidigare registrerades.

   DNS-servern kontrollerar också att uppdateringar tillåts för klientbegäran. För primära standardzoner skyddas inte dynamiska uppdateringar, så alla klientuppdateringsförsök lyckas. För Active Directory-integrerade zoner skyddas och utförs uppdateringar med hjälp av katalogbaserade säkerhetsinställningar. Mer information finns i avsnittet Skydda dynamisk uppdatering senare i den här artikeln.

Dynamiska uppdateringar skickas eller uppdateras regelbundet. Som standard skickar datorer en uppdatering var sjunde dag. Om uppdateringen inte resulterar i några ändringar i zondata förblir zonen i den aktuella versionen och inga ändringar skrivs. Uppdateringar resulterar i zonändringar eller ökade zonöverföringar endast när namn eller adresser ändras.

Namn tas inte bort från DNS-zoner om de blir inaktiva eller inte uppdateras inom uppdateringsintervallet (sju dagar). DNS har ingen mekanism för att frigöra eller gravstensnamn. DNS-klienter försöker dock ta bort gamla namnposter när ett nytt namn används. DNS-klienter försöker också uppdatera namnposter när en adressändring sker.

När DNS-klienttjänsten registrerar A- och PTR-resursposter för en dator använder den en standardcachelagringstid (TTL) på 15 minuter för värdposter. Denna TTL avgör hur länge andra DNS-servrar och -klienter cachelagrar en dators poster när de ingår i ett frågesvar.

Tid att leva

När en dynamisk uppdateringsklient registreras i DNS inkluderar de associerade A- och PTR-resursposterna TTL (Time to Live). Som standard är TTL inställt på 10 minuter för poster som registrerats av Netlogon-tjänsten. För poster som registrerats av DHCP-klienttjänsten är TTL inställt på 15 minuter. Om DNS Server-tjänsten dynamiskt registrerar poster för sina egna zoner är standard-TTL 20 minuter. Du kan ändra standardinställningen i registret. Ett litet värde gör att cachelagrade poster upphör att gälla tidigare, vilket ökar DNS-trafiken men minskar risken för att cachelagrade poster blir inaktuella. Att låta poster snabbt utlöpa är användbart för datorer som ofta förnyar sina DHCP-anstånd. Långa kvarhållningstider är användbara för datorer som förnyar sina DHCP-lån sällan.

Lösa namnkonflikter

När DNS-klienttjänsten försöker registrera en A-post kontrollerar den om den auktoritativa DNS-zonen redan innehåller en A-post för samma namn men med en annan IP-adress. Som standard försöker DNS-klienttjänsten ersätta den befintliga A-posten (eller posterna) med den nya A-posten som innehåller DNS-klientens IP-adress. Därför kan alla datorer i nätverket ändra den befintliga A-posten om inte säker dynamisk uppdatering används. Zoner som har konfigurerats för säker dynamisk uppdatering tillåter endast behöriga användare att ändra resursposten.

Du kan ändra standardinställningen så att DNS-klienttjänsten avslutar registreringsprocessen och loggar felet i Loggboken i stället för att ersätta den befintliga A-posten. Mer information finns i avsnittet Skydda dynamisk uppdatering senare i den här artikeln.

DNS och DHCP

Windows DNS-klienter är dynamiska uppdateringsmedvetna och kan initiera den dynamiska uppdateringsprocessen. En DNS-klient förhandlar om processen för dynamisk uppdatering med DHCP-servern när klienten lånar en IP-adress eller förnyar lånet. Den här förhandlingen avgör vilken dator som uppdaterar A- och PTR-resursposterna för klienten. DNS-klienten och DHCP-servern kommer överens om vem som uppdaterar posterna. Klienten och servern skickar begäranden om dynamisk uppdatering till de primära DNS-servrar som är auktoritativa för att namnen ska uppdateras.

Tjänsten Windows Server DHCP Server kan uppdatera DNS-poster för klienter som inte stöder FQDN-alternativet för DHCP-klienttjänsten. Den här funktionen kan aktiveras på fliken DNS i serveregenskaperna för DHCP-konsolen. DHCP-servern hämtar först namnet på äldre klienter från DHCP REQUEST paketet. Den lägger sedan till domännamnet som angetts för det omfånget och registrerar A- och PTR-resursposterna.

I vissa fall kan inaktuella PTR- eller A-resursposter visas på DNS-servrar när lånet för en DHCP-klient upphör att gälla. När en DNS-klient till exempel försöker förhandla om en dynamisk uppdateringsprocedur med en DHCP-server måste DNS-klienten registrera både A- och PTR-resursposterna. Om klienten senare tas bort felaktigt från nätverket kan klienten inte avregistrera sina A- och PTR-resursposter och de blir inaktuella.

Om en inaktuell en resurspost visas i en zon som endast tillåter säkra dynamiska uppdateringar, kan ingen dator registrera någon annan resurspost för namnet i den resursposten. För att förhindra problem med inaktuella PTR- och A-resursposter kan du aktivera funktionen för åldrande och rensning. Mer information om funktionen för åldrande och rensning finns i DNS-åldrande och rensning.

Om du vill tillhandahålla feltolerans för dynamiska uppdateringar bör du överväga Active Directory-integrering för de zoner som accepterar dynamiska uppdateringar från Windows-klienter. För att påskynda identifieringen av auktoritativa DNS-servrar kan du konfigurera varje klient med en lista över önskade och alternativa DNS-servrar som är primära för den katalogintegrerade zonen. Om en klient inte kan uppdatera zonen med önskad DNS-server eftersom DNS-servern inte är tillgänglig kan klienten prova en alternativ server. När den önskade DNS-servern blir tillgänglig läser den in den uppdaterade, katalogintegrerade zonen som innehåller uppdateringen från klienten.

Dynamisk uppdateringsprocess

I det här avsnittet beskriver vi den dynamiska uppdateringsprocessen för DHCP-klienter, statiskt konfigurerade klienter, fjärråtkomstklienter och multihomed-klienter.

DHCP-klientprocess

För att initiera den dynamiska uppdateringsprocessen skickar DHCP-klienten sitt FQDN till DHCP-servern i DHCPREQUEST paketet med hjälp av alternativet FQDN för DHCP-klienttjänsten. DHCP-servern svarar sedan på DHCP-klienten genom att skicka ett DHCP-bekräftelsemeddelande (DHCPACK) som innehåller alternativet FQDN (alternativkod 81).

I följande tabell visas fälten i alternativet FQDN för DHCPREQUEST paketet.

Field	Explanation
Code	Anger koden för det här alternativet (81).
Len	Anger längden i oktetter för det här alternativet (minst 4).
Flags	Kan vara något av följande värden: 0. Klienten vill registrera en resurspost och begär att servern uppdaterar PTR-resursposten. 1. Klienten vill att servern ska registrera A- och PTR-resursposterna. 3. DHCP-servern registrerar A- och PTR-resursposterna oavsett klientens begäran.
RCODE1 och RCODE2	DHCP-servern använder dessa fält för att ange svarskoden från A- och PTR-resursregistreringarna som utförs för klientens räkning och för att ange om den försökte uppdatera innan den skickade DHCPACK.
Domännamn	Anger FQDN för klienten.

Under vilka villkor DHCP-klienter skickar FQDN-alternativet beror på vilket operativsystem klienten kör och hur klienten är konfigurerad. De åtgärder som vidtas av DHCP-servrar beror också på vilket operativsystem servern kör och hur servern är konfigurerad.

Som standard använder Windows DHCP-klienttjänsten följande process.

1. Windows DHCP-klienttjänsten skickar FQDN-alternativet med fältet Flaggor inställt på 0. Den här flaggan begär att klienten uppdaterar A-resursposten, och DHCP Server-tjänsten uppdaterar PTR-resursposten.

2. Klienten väntar på ett svar från DHCP-servern. Om inte DHCP-servern anger fältet Flaggor till 3 initierar DNS-klienten sedan en uppdatering för A-resursposten.

3. Om DHCP-servern inte stöder eller inte har konfigurerats för registrering av DNS-posten ingår inte ett FQDN i svaret. I det här fallet försöker DNS-klienten registrera A- och PTR-resursposterna.

Beroende på vad DHCP-klienten begär kan DHCP-servern vidta olika åtgärder.

Om DHCP-klienten skickar ett DHCPREQUEST meddelande utan alternativet FQDN beror beteendet på typen av DHCP-server och dess konfiguration. DHCP-servern uppdaterar båda posterna om du konfigurerar den för att uppdatera poster för DHCP-klienter som inte stöder FQDN-alternativet.

I följande fall utför INTE DHCP-servern någon åtgärd:

• DHCP-servern stöder inte dynamisk uppdatering.

• DHCP-servern är konfigurerad att inte göra dynamiska uppdateringar för klienter som inte stöder FQDN-alternativet.

• DHCP-servern är konfigurerad att inte registrera DNS-resursposter.

Om Windows DHCP-klienten begär att servern uppdaterar PTR-resursposten men inte A-resursposten beror beteendet på typen av DHCP-server och dess konfiguration.

Servern kan utföra någon av följande åtgärder:

• Om Windows DHCP-servern har konfigurerats för att inte utföra dynamiska uppdateringar innehåller den inte alternativet FQDN i svaret. Den uppdaterar inte heller någon av resursposterna. I det här fallet försöker DNS-klienten uppdatera både A- och PTR-resursposterna om den är kapabel.

• Om Windows DHCP-servern är konfigurerad att uppdateras enligt DHCP-klientens begäran försöker servern uppdatera PTR-resursposten. DHCP-servern skickar ett DHCPACK meddelande till DHCP-klienten. Det här meddelandet innehåller alternativet FQDN med fältet Flaggor inställt på 0. Meddelandet DHCPACK bekräftar att DHCP-servern uppdaterar PTR-posten. DNS-klienten försöker sedan uppdatera A-resursposten, om den är kapabel.

• Om DHCP-servern är konfigurerad för att alltid uppdatera A- och PTR-båda posterna försöker DHCP-servern uppdatera båda resursposterna. DHCP-servermeddelandet DHCPACK till DHCP-klienten innehåller alternativet FQDN med fältet Flaggor inställt på 3och meddelar DHCP-klienten att DHCP-servern uppdaterar A- och PTR-poster. I det här fallet försöker DNS-klienten inte uppdatera någon av resursposterna.

Statisk konfigurerade och fjärråtkomstklienters processer

Statiskt konfigurerade klienter och fjärråtkomstklienter förlitar sig inte på DHCP-servern för DNS-registrering. Statiskt konfigurerade klienter uppdaterar dynamiskt sina A- och PTR-resursposter varje gång de startar. Klienter uppdateras också var 24:e timme för att uppdatera poster i DNS-databasen.

Fjärråtkomstklienter kan dynamiskt uppdatera A- och PTR-resursposter när en uppringningsanslutning skapas. De kan också försöka dra tillbaka, eller avregistrera, A- och PTR-resursposterna när användaren stänger anslutningen explicit. Datorer som kör Windows Server med en fjärråtkomstnätverksanslutning försöker dynamiskt registrera A- och PTR-posterna för IP-adressen för den här anslutningen. Som standard försöker INTE DNS-klienttjänsten på Windows-klienten dynamisk uppdatering via en fjärråtkomst eller VPN-anslutning. Om du vill ändra den här konfigurationen kan du ändra de avancerade TCP/IP-inställningarna för den specifika nätverksanslutningen eller ändra registret.

Om en fjärråtkomstklient i alla operativsystem inte får ett lyckat svar från försöket att avregistrera en DNS-resurspost, eller av någon annan anledning misslyckas med att avregistrera en resurspost inom fyra sekunder, stänger DNS-klienten anslutningen. I sådana fall kan DNS-databasen innehålla en inaktuell postering.

Om fjärråtkomstklienten inte avregistrerar en DNS-resurspost läggs ett meddelande till i händelseloggen, som du kan visa med hjälp av Loggboken. Fjärråtkomstklienten tar aldrig bort inaktuella poster, men fjärråtkomstservern försöker avregistrera PTR-resursposten när klienten är frånkopplad.

Windows DNS-klienttjänsten försöker som standard inte uppdatera A- och PTR-poster automatiskt för uppringningsanslutningar.

Multihomed-klientprocess

Om en dynamisk uppdateringsklient är multihomed, vilket innebär att klienten har mer än en nätverksanslutning och tillhörande IP-adress, registreras alla IP-adresser för varje nätverksanslutning. Om du inte vill att den ska registrera dessa IP-adresser kan du konfigurera nätverksanslutningen så att den inte registrerar IP-adresser.

Klienten för dynamisk uppdatering registrerar inte alla IP-adresser med DNS-servrarna i alla namnområden som datorn är ansluten till. Till exempel är en multihoming-dator, client1.example.contoso.com, ansluten till både Internet och företagets intranät. Klienten är ansluten till intranätet via adapter A, ett DHCP-kort med IP-adressen 172.16.8.7. Klienten är också ansluten till Internet via kort B, ett fjärråtkomstkort med IP-adressen 10.3.3.9. Klienten löser intranätnamn med hjälp av en namnserver i intranätet och löser Internetnamn med hjälp av en namnserver på Internet.

Säker dynamisk uppdatering

DNS-uppdateringssäkerhet är endast tillgängligt för zoner som är integrerade i Active Directory. När du integrerar en zon i Active Directory är åtkomstkontrollistor (ACL) tillgängliga i DNS-konsolen så att du kan lägga till eller ta bort användare och grupper från ACL för en angiven zon eller resurspost. ACL:er är endast för åtkomstkontroll för DNS-administration och påverkar inte DNS-frågematchning.

Som standard hanteras dynamisk uppdateringssäkerhet för DNS-servrar och -klienter på följande sätt:

• DNS-klienter försöker först använda oskyddad dynamisk uppdatering. Om en oskyddad uppdatering nekas försöker klienterna använda säker uppdatering.

  Standardprincipen för uppdatering tillåter klienter att försöka skriva över en tidigare registrerad resurspost, såvida den inte blockeras.

• När en zon har blivit Active Directory-integrerad kan DNS-servrar som kör Windows Server som standard endast tillåta säkra dynamiska uppdateringar.

  När du använder filbaserad zonlagring är standardvärdet för DNS Server-tjänsten att inte tillåta dynamiska uppdateringar i dess zoner. För zoner som antingen är katalogintegrerade eller använder standardfilbaserad lagring kan du ändra zonen så att alla dynamiska uppdateringar tillåts. Den här inställningen tillåter att alla uppdateringar godkänns.

Dynamisk uppdatering är ett tillägg till DNS-standardspecifikationen som definieras i RFC 2136.

Dynamisk registrering av DNS-resursposter kan begränsas med hjälp av registerposter.

Så här fungerar säker dynamisk uppdatering

Den säkra dynamiska uppdateringsprocessen beskrivs på följande sätt:

1. För att initiera en säker dynamisk uppdatering initierar DNS-klienten först förhandlingsprocessen för säkerhetskontexten, under vilken token skickas mellan klient och server med hjälp av TKEY-resursposter. I slutet av förhandlingsprocessen upprättas säkerhetskontexten.

2. DNS-klienten skickar begäran om dynamisk uppdatering till DNS-servern. Den här begäran innehåller resursposter för att lägga till, ta bort eller ändra data.

   1. Begäran signeras med hjälp av den tidigare etablerade säkerhetskontexten.

   2. Signaturen skickas i TSIG-resursposten, som ingår i det dynamiska uppdateringspaketet.

3. Servern försöker uppdatera Active Directory med klientens autentiseringsuppgifter och skickar resultatet av uppdateringen till klienten. Dessa resultat signeras också med hjälp av säkerhetskontexten och signaturen som skickas i TSIG-resursposten som ingår i svaret.

Säker process för dynamisk uppdatering

Den säkra dynamiska uppdateringsprocessen beskrivs på följande sätt:

1. DNS-klienten frågar den önskade DNS-servern för att avgöra vilken DNS-server som är auktoritativ för det domännamn som den försöker uppdatera. Den önskade DNS-servern svarar med namnet på zonen och den primära DNS-servern som är auktoritativ för zonen.

2. DNS-klienten försöker utföra en dynamisk standarduppdatering och om zonen är konfigurerad för att endast tillåta säkra dynamiska uppdateringar (standardkonfigurationen för Active Directory-integrerade zoner) nekar DNS-servern den icke-säkra uppdateringen. Om zonen är konfigurerad för dynamisk standarduppdatering i stället för säker dynamisk uppdatering godkänner DNS-servern DNS-klientens försök att lägga till, ta bort eller ändra resursposter i den zonen.

3. DNS-klienten och DNS-servern påbörjar TKEY-förhandling.

   1. DNS-klienten och DNS-servern förhandlar om en underliggande säkerhetsmekanism. Windows dynamiska uppdateringsklienter och DNS-servrar kan bara använda Kerberos-protokollet.

   2. Med hjälp av säkerhetsmekanismen verifierar DNS-klienten och DNS-servern sina respektive identiteter och upprättar säkerhetskontexten.

4. DNS-klienten skickar begäran om dynamisk uppdatering till DNS-servern, signerad med den etablerade säkerhetskontexten. Signaturen ingår i signaturfältet för TSIG-resursposten som ingår i paketet för begäran om dynamisk uppdatering. DNS-servern verifierar ursprunget för det dynamiska uppdateringspaketet med hjälp av säkerhetskontexten och TSIG-signaturen.

5. DNS-servern försöker lägga till, ta bort eller ändra resursposter i Active Directory. Uppdateringen beror på om DNS-klienten har rätt behörigheter och om förutsättningarna är uppfyllda.

6. DNS-servern skickar ett svar till DNS-klienten som anger om den kunde göra uppdateringen, signerad med den etablerade säkerhetskontexten. Signaturen ingår i signaturfältet för TSIG-resursposten som ingår i svarspaketet för dynamisk uppdatering. Om DNS-klienten får ett förfalskat svar ignoreras det och väntar på ett signerat svar.

Säkerhet för DHCP-klienter som inte stöder FQDN-alternativet

Windows DHCP-klienter som inte stöder FQDN-alternativet (alternativ 81) kan inte få dynamiska uppdateringar. Om du vill att A- och PTR-resursposterna för dessa klienter ska registreras dynamiskt i DNS måste du konfigurera DHCP-servern så att den utför dynamiska uppdateringar åt dem.

Om DHCP-servern ska utföra säkra dynamiska uppdateringar för DHCP-klienter som inte stöder FQDN-alternativet krävs extra konfiguration för att undvika ett behörighetsproblem. När en DHCP-server utför en säker dynamisk uppdatering på ett namn blir den ägare till det namnet. Endast den DHCP-servern kan uppdatera alla poster för det namnet.

Anta till exempel att DHCP-servern DHCP1 skapade ett objekt för namnet host1.example.com och sedan slutade svara, och att senare backup-DHCP-servern, DHCP2, försökte uppdatera en post med samma namn, host1.example.com. I det här fallet kan DHCP2 inte uppdatera namnet eftersom det inte äger namnet.

Undvik det här problemet genom att använda den inbyggda säkerhetsgruppen DnsUpdateProxy. Om du lägger till alla DHCP-servrar som medlemmar i gruppen DnsUpdateProxy kan en annan server uppdatera en servers poster om den första servern misslyckas. Eftersom alla objekt som skapats av medlemmarna i gruppen DnsUpdateProxy inte skyddas blir den första användaren som ändrar den uppsättning poster som är associerade med ett DNS-namn dess ägare. När äldre klienter uppgraderas kan de ta över ägarskapet för sina namnposter på DNS-servern. Om varje DHCP-server som registrerar resursposter för äldre klienter är medlem i gruppen DnsUpdateProxy uppstår inte de problem som beskrevs tidigare.

Skydda poster med hjälp av gruppen DnsUpdateProxy

När DHCP-servern är medlem i gruppen DnsUpdateProxy skyddas inte de DNS-domännamn som registreras. Därför ska du inte använda den här gruppen i en integrerad Active Directory-zon som endast tillåter säkra dynamiska uppdateringar utan att vidta fler åtgärder för att tillåta att poster som skapats av medlemmar i gruppen skyddas.

Skapa ett dedikerat användarkonto för att skydda mot oskyddade poster eller för att tillåta medlemmar i gruppen DnsUpdateProxy att registrera poster i zoner som endast tillåter skyddade dynamiska uppdateringar. Med autentiseringsuppgifterna för det här användarkontot konfigurerar du DHCP-servrar för att utföra dynamiska DNS-uppdateringar. Flera DHCP-servrar kan använda autentiseringsuppgifterna för ett dedikerat användarkonto.

Det dedikerade användarkontot är ett standardanvändarkonto som endast används för att tillhandahålla DHCP-servrar med autentiseringsuppgifter för registrering av dynamisk DNS-uppdatering. Varje DHCP-server tillhandahåller dessa autentiseringsuppgifter när namn registreras för DHCP-klienter som använder dynamisk DNS-uppdatering. Det dedikerade användarkontot skapas i samma skog där den primära DNS-servern för zonen som ska uppdateras finns. Det dedikerade användarkontot kan också finnas i en annan skog så länge skogen den finns i har ett skogsförtroende upprättat med skogen som innehåller den primära DNS-servern för zonen som ska uppdateras.

När den installeras på en domänkontrollant ärver DHCP Server-tjänsten säkerhetsbehörigheterna för domänkontrollanten. Det innebär att den har behörighet att uppdatera eller ta bort dns-poster som är registrerade i en säker Active Directory-integrerad zon. Andra datorer som kör Windows Server, till exempel domänkontrollanter, registrerar dessa poster på ett säkert sätt. När den installeras på en domänkontrollant konfigurerar du DHCP-servern med autentiseringsuppgifterna för det dedikerade användarkontot för att förhindra att servern ärver och eventuellt missbrukar domänkontrollantens behörigheter.

Konfigurera ett dedikerat användarkonto och konfigurera DHCP Server-tjänsten med kontoautentiseringsuppgifterna under följande omständigheter:

• En domänkontrollant har konfigurerats för att fungera som en DHCP-server.
• DHCP-servern är konfigurerad för att utföra dynamiska DNS-uppdateringar för DHCP-klienters räkning.
• DHCP-servern uppdaterar DNS-zoner som är konfigurerade för att endast tillåta säkra dynamiska uppdateringar.

När du har skapat ett dedikerat användarkonto kan du konfigurera DHCP-servrar med autentiseringsuppgifterna för användarkontot med hjälp av DHCP-konsolen eller med hjälp av kommandot netsh dhcp server set dnscredentials.

Note

• Om de angivna autentiseringsuppgifterna tillhör ett objekt som är medlem i säkerhetsgruppen DnsUpdateProxy blir nästa objekt som registrerar samma namnpost i DNS postägaren.

• Om du anger autentiseringsuppgifter för DHCP-servern som ska användas när du registrerar DHCP-klientdatorer i DNS säkerhetskopieras inte dessa autentiseringsuppgifter. När en DHCP-databas har återställts måste nya autentiseringsuppgifter konfigureras.