Dela via

Felsöka problem med dynamisk DNS-uppdatering

Den här guiden tar upp vanliga problem som rör dynamiska dns-uppdateringar (domain name system) och tillhandahåller relevanta felsökningssteg. Dynamiska uppdateringar är avgörande för att upprätthålla korrekta DNS-poster, särskilt i miljöer där IP-adresser ändras ofta, till exempel DHCP (Dynamic Host Configuration Protocol). Guiden beskriver vanliga scenarier, rekommendationer och felsökningstips för DNS-klienter, DHCP-servrar och DNS-servrar.

Allmänna orsaker

Här är de allmänna orsakerna till dynamiska uppdateringsfel:

  • DNS-klienten skickar inte dynamiska uppdateringar.
  • DHCP är tänkt att uppdatera posten, men den funktionen fungerar inte som förväntat.
  • DNS-servern uppdaterar inte posten på grund av behörighetsproblem.

Innan du felsöker rekommenderar vi att du implementerar följande metodtips.

Microsofts standardrekommendationer

DNS-registrering på klientsidan

I många miljöer uppdaterar DHCP DNS-posten för klientens räkning. Med tanke på infrastrukturens hybridkaraktär i dessa dagar och anställda som använder virtuella privata nätverk (VPN) för att ansluta till kontoret, finns det ofta mer än en IP-adress som är associerad med en slutpunkt. Den här situationen kan undvikas om klienten registrerar sina poster. Rekommendationen är därför inte att använda DHCP-alternativ 81 och i stället låta klienten registrera sina poster.

Mer information om hur DHCP-alternativ 81 fungerar finns i följande två artiklar:

Konfigurera dynamiska uppdateringar som "Endast säker"

Den dynamiska uppdateringen i domänzonen ska endast konfigureras som Säker.

Om klientdatorer som utför dynamisk registrering är domänanslutna (som ska verifieras av domänens administratör eller lösningsarkitekt) konfigurerar du domänzonen för att tillåta dynamiska uppdateringar med Säker endast för att säkerställa konsekvent beteende för den dynamiska registreringen.

Aktivera tidsstämplar för dynamiska poster

Dynamiska poster innehåller som standard inte någon tidsstämpel. När du konfigurerar zonegenskaper kan du aktivera alternativet Rensa inaktuella poster under avsnittet Åldrande i zonens egenskapsdialogruta. När det här alternativet har aktiverats innehåller nyligen registrerade poster en tidsstämpel.

Tidsstämplarna krävs om du planerar att rensa inaktuella poster. Utan en tidsstämpel kan en DNS-post inte jämföras med den aktuella tiden och anses inte vara inaktuell, även om den har registrerats dynamiskt.

Kommentar

Om du nyligen har aktiverat det angivna alternativet kommer posterna som registrerades före ändringen inte att ha någon tidsstämpel eller rensas.

Rensa inställningar för DNS i en AD-integrerad zon

Alternativet Rensa inaktuella poster i zonens egenskaper för åldrande säkerställer att Active Directory-objekt (AD) har en tidsstämpel. Den faktiska rensningen av inaktuella poster sker dock på DNS-servernivå, vilket påverkar alla zoner där den här inställningen är aktiverad. En detaljerad förklaring av rensning finns i KONFIGURATION av DNS-rensning.

Rensningscykeln är en tråd med låg prioritet i DNS-processen, så den kanske inte alltid körs konsekvent. För att maximera risken för att den körs konfigurerar du rensning på en domänkontrollants (DC) DNS-server i en AD-integrerad zonmiljö som inte har kritiska roller, till exempel FSMO-roller (Flexible Single Master Operation) och undviker särskilt PDC-emulatorn (Primary Domain Controller). Helst bör rensning konfigureras på en domänkontrollant utan FSMO-roller. Om den här konfigurationen inte är möjlig kan du undvika att konfigurera den på PDC-emulatorn.

Underhålla standardbehörigheter för DNS-zonen

Standardbehörigheter för DNS-zonen bör förbli intakta.

I en AD-integrerad zonkonfiguration följer behörigheterna en standardhierarki som liknar NTFS (New Technology File System) eller filsystem. Det innebär att om ett konto har behörighet att skapa, ta bort eller ändra en zon och dess underordnade objekt kan det utföra dessa åtgärder. Som standard har endast företagsadministratörer (hela skogen) och domänadministratörer (domänomfattande) dessa behörigheter.

När Endast säkra dynamiska uppdateringar är aktiverade kan ett autentiserat konto (till exempel en domänansluten dator) uppdatera, ta bort eller ändra en DNS-post om kontot är ägare till posten. Detta säkerställer att endast den ursprungliga skaparen av posten kan ändra eller ta bort den, vilket är det avsedda beteendet för endast säkra dynamiska uppdateringar.

Det kan dock uppstå utmaningar när en DHCP-server uppdaterar DNS-poster för klienters räkning med hjälp av dhcp-alternativet (fullständigt kvalificerat domännamn) (FQDN) (alternativ 81). I sådana fall kan inkonsekvenser uppstå eftersom DNS-poster som uppdateras av DHCP-servern inte kan ändras av den ursprungliga klienten och vice versa.

Som tidigare nämnts rekommenderar vi att klientdatorer uppdaterar sina egna DNS-poster i stället för att förlita sig på DHCP-servern. Detta beror på flera orsaker, och Microsoft har också implementerat en designändring för att framtvinga det här beteendet. Den här ändringen hindrar DHCP-servern från att uppdatera både A- och PTR-poster för klienter. Information om hur du åsidosätter det här beteendet finns i Oväntat registreringsbeteende för DNS-poster om DHCP-servern använder "Uppdatera alltid DNS-poster dynamiskt".

Helst bör klienten uppdatera sina egna DNS-poster. Men om en post tidigare uppdaterades av DHCP-servern kan den faktiska klienten inte ändra den. För att lösa det här problemet tvingar vissa företag DHCP-servern att fortsätta uppdatera klientens poster, vilket är starkt avrådt.

Den rekommenderade metoden är att låta DHCP-servern eller rensningsprocessen ta bort posterna. När de har tagits bort kan klienten uppdatera dem.

Avgränsa DHCP-servern från ADDS

DHCP-servern ska finnas på en separat server, inte på en domänkontrollant som kör Active Directory-domän Services (ADDS).

I en säker uppdateringskonfiguration använder DHCP-servern datorns domänkonto för att registrera DNS-poster. När DHCP-servern körs på en domänkontrollant använder den domänkontrollantens konto för att registrera poster. Det innebär att statiska poster kan skrivas över av DHCP-servern om alternativet FQDN är aktiverat och DHCP-servern inte har konfigurerats med ett dedikerat tjänstkonto. Detta kan orsaka problem som oavsiktlig rensning av statiska poster.

För att förhindra sådana problem bör DHCP-servern konfigureras med ett tjänstkonto och köras på en separat server. Mer information finns i Konfigurera dynamiska DNS-uppdateringar i Windows.

Felsöka allmänna och kända problem

Problem på klientsidan

DHCP-serverproblem

DNS-serverproblem

  • Behörighetsproblem med DNS-zoner.
  • Ändringar i inställningarna för autentiserade konton på DNS-zonnivå.
  • DHCP:s konfiguration av tjänstkontot för dynamiska uppdateringar.

Felsöka problem med dynamisk DNS-uppdatering

Kommentar

I det här avsnittet i flera delar beskrivs olika aspekter från Windows-klienten till servern som ska kontrolleras när ett sådant problem uppstår.

Du måste börja med grundläggande kontroller, till exempel att avgöra om problemet påverkar flera klienter, klienter i samma undernät eller en specifik klient. Detta hjälper till att begränsa om problemet ligger hos klienten, servern eller nätverket. En förklaring av hur dynamiska DNS-uppdateringar utlöses, inklusive exempel, finns i Konfigurera dynamiska DNS-uppdateringar i Windows.

När du har förstått de dynamiska DNS-uppdateringarna kan du använda följande checklista för att säkerställa att klientens dynamics update-inställningar finns på plats.

Checklista på DNS-klientsidan

Kontrollera om Registrera den här anslutningens adresser i DNS har valts:

#Get the list of interfaces that are up and connected.
$Adapters = Get-NetAdapter | Where-Object Status -eq Up

#If there's only one interface, the following command will work.
Get-DnsClient -InterfaceIndex $Adapters.ifIndex

#If more than one interface is active and up, you can use "Get-DNSClient" to see the registration status of all interfaces.

I utdata ska RegisterThisConnectionsAddress vara True. Ändra värdet till Sant om det är Falskt:

#Get the list of interfaces that are up and connected.
$Adapters = Get-NetAdapter | Where-Object Status -eq Up

#If there's only one interface, the following command will work.
Set-DnsClient -RegisterThisConnectionsAddress $True -InterfaceIndex $Adapters.ifIndex

Kontrollera värdet genom att ta Get-DnsClient utdata och se till att RegisterThisConnectionsAddress är inställt på Sant.

Det finns en grupprincip som kan ändra det här beteendet. Som standard är nätverksgränssnitt inställda på att registrera sina anslutningar. Ett företag kan dock använda grupprincipinställningen Dynamisk uppdatering för att styra hur en klient skickar dynamiska DNS-uppdateringar. Grupprincipen finns på:

Dynamisk uppdatering av nätverks-DNS-klient för datorkonfiguration>administrativa mallar>>>

Checklista på DNS-serversidan

Kontrollera att zonen är skrivbar

Domänen där klienten är dynamiskt registrerad måste vara en skrivbar kopieringszon. Det innebär att zonen ska innehålla en SOA-post för DNS-servern som är värd för den, och klienten måste kunna nå den här servern via nätverket.

Det finns vanligtvis två typer av installationer:

  1. Klient som pekar på en CACHE-endast DNS-server: Den här DNS-servern är inte värd för någon domänzon, men använder villkorliga vidarebefordrare eller vidarebefordrare för att peka på den faktiska DNS-servern, som innehåller zonen (antingen skrivbar eller läsbar).
  2. Enkel konfiguration: Klienten pekar direkt på DNS-servrar som är värdar för domänzonen.

Alternativ ett väljs vanligtvis för belastningsutjämning och en större miljö med många klienter. Tanken är att flytta belastningen på namnmatchningen från tillgängliga domänkontrollanter till extra servrar. I den här konfigurationen måste klienten dock ha anslutning för DNS-protokollet till servern som är värd för SOA-posten för domänzonen. Annars misslyckas den dynamiska uppdateringen.

Tillåt dynamiska uppdateringar

En AD-integrerad DNS-zon som finns på en Microsoft DNS-server har tre alternativ för dynamiska uppdateringar:

  • None
  • Osäker och säker
  • Endast säker

Kommentar

Det sista alternativet är endast tillgängligt för AD-integrerade DNS-zoner.

Om du vill tillåta dynamiska uppdateringar bör zonen konfigureras med uppdateringstypen Ej säker och säker eller Endast säker. Säker rekommenderas endast för AD-integrerade zoner.

Kontrollera DNS-granskning

DNS-serverloggning beskrivs i DNS-loggning och diagnostik. Mer specifikt syftar det till att kontrollera om de poster som du är orolig för är registrerade och kan spåras med DNS-granskningshändelser, händelse-ID 519. Du kan filtrera DNS-granskningshändelserna aktiverade som standard med det angivna ID:t och kontrollera om posten har registrerats.

Kommentar

Händelseloggen Granskning är lokal för den angivna DNS-servern, vilket innebär att det angivna ID:t endast visas på DNS-servern där posten är registrerad.

Scenario: DHCP-servern kan inte slutföra dynamiska uppdateringar för klientens räkning, eller så fördröjs registreringarna

DHCP-servern är konfigurerad för att uppdatera DHCP-klientens poster. Konfigurationen anges i Konfigurera dynamiska DNS-uppdateringar i Windows. Windows-klienterna är också konfigurerade för att uppfylla DHCP-alternativ 81. De konfigureras som nämnts i Oväntat registreringsbeteende för DNS-poster när DHCP-servern hanterar dynamiska DNS-uppdateringar.

Kommentar

Vi rekommenderar att klienten registrerar sin post i stället för DHCP eller någon annan enhet.

Med alla konfigurationer på plats kan DNS-posten registreras med en betydande fördröjning eller kanske inte registreras alls. Du kan kontrollera detta genom att kontrollera DHCP-serverns granskningsloggar som finns i de dagliga granskningsfilerna på C:\Windows\System32\DHCP.

Viktigt!

Ett liknande problem diskuteras i DHCP-dynamiska uppdateringar av DNS-registreringar fördröjs eller bearbetas inte.

Orsak

Det finns olika orsaker till varför det här problemet kan uppstå, men en vanlig orsak är att DHCP-serverns dns-kö för dynamisk uppdatering är full, vilket innebär att den inte kan bearbeta nya begäranden. Det här problemet inträffar vanligtvis av två huvudsakliga orsaker:

  1. DNS-servrarna (konfigurerade i DHCP-omfånget) returnerar inte ett SOA-svar eftersom SOA-frågan är för en omvänd uppslagszon som inte har konfigurerats på DNS-servrarna.
  2. Inget SOA-svar eller dynamiska uppdateringar tillåts inte på SOA-servern. Mer information finns i DHCP-dynamiska uppdateringar av DNS-registreringar fördröjs eller bearbetas inte.

Lösning: Skapa omvända uppslagszoner på DNS-servrarna

Metod 1

Kontrollera och kontakta nätverksteamet och DHCP-konfigurationen för att få en lista över alla omfång/undernät i nätverket. Skapa en omvänd sökning för varje sådant undernät. Den här metoden fungerar för både omvända IPv4- och IPv6-uppslagszoner.

Metod 2

Undvik utelämnanden genom att skapa en zon med ett privat IP-rotintervall. Till exempel:

  • 168.192.in-addr.arpa
  • 16.172.in-addr.arpa
  • 10.in-addr.arpa

Detta omfattar alla undernätsintervall för IPv4-adresser i miljön. Om du redan har skapat några omvända uppslagszoner blir de automatiskt en delegering i dessa zoner.

Förklaring

När DHCP-alternativ 81 har konfigurerats kontrollerar DHCP-servern det FQDN som returneras av klienten och begär dess SOA från de DNS-servrar som konfigurerats i omfånget. Om SOA inte returneras placeras begäran i kö för ett nytt försök. När en omvänd uppslagszon saknas tenderar kön att fyllas, eftersom det kommer att finnas en begäran för varje lån men ingen zon för att registrera PTR-posten. Om dynamiska uppdateringar är inaktiverade på SOA-servern eller om SOA-servern inte kan nås, fylls också kön på för framåtriktade sökningar.