Felsökningsguide för Azure DNS

  • Artikel

Den här artikeln innehåller felsökningsinformation för vanliga Azure DNS-frågor.

Om de här stegen inte löser problemet kan du även söka efter eller publicera ditt problem på vår frågesida för Microsoft Q&A för community-support. Eller så kan du öppna en Azure-supportbegäran.

Jag kan inte skapa en DNS-zon

Prova ett eller flera av följande steg för att lösa vanliga problem:

  1. Granska Azure DNS-granskningsloggarna för att fastställa orsaken till felet.
  2. Varje DNS-zonnamn måste vara unikt inom sin resursgrupp. Två DNS-zoner med samma namn kan alltså inte dela en resursgrupp. Försök med ett annat zonnamn eller en annan resursgrupp.
  3. Du kan se felet "Du har nått eller överskridit det maximala antalet zoner i prenumerationen {prenumerations-ID}.". Använd antingen en annan Azure-prenumeration, ta bort vissa zoner eller kontakta Azure Support för att höja prenumerationsgränsen.
  4. Du kan se felet "Zonen {zonnamn} är inte tillgänglig." Det här felet innebär att Azure DNS inte kunde allokera namnservrar för den här DNS-zonen. Försök med ett annat zonnamn. Eller om du är domännamnsägare kan du kontakta Azure-supporten för att allokera namnservrar åt dig.

Jag kan inte skapa någon DNS-post

Prova ett eller flera av följande steg för att lösa vanliga problem:

  1. Granska Azure DNS-granskningsloggarna för att fastställa orsaken till felet.
  2. Finns postuppsättningen redan? Azure DNS hanterar poster med postuppsättningar, vilket är en samling av poster med samma namn och av samma typ. Om det redan finns en post med samma namn och typ, redigerar du den befintliga postuppsättningen om du vill lägga till ännu en post.
  3. Försöker du skapa en post i DNS-basdomänen (zonens ”rot”)? Om så är fallet använder DNS-konventionen tecknet ”@” som postens namn. Observera också att DNS-standarderna inte tillåter CNAME-poster i zonens topp.
  4. Har du en CNAME-konflikt? DNS-standarderna tillåter inte en CNAME-post med samma namn som en post av någon annan typ. Om du har ett befintligt CNAME kommer du att misslyckas om du försöker skapa en post med samma namn och av en annan typ. På samma sätt går det inte att skapa ett CNAME om namnet matchar en befintlig post av en annan typ. Lös konflikten genom att ta bort den andra posten eller välja ett annat postnamn.
  5. Har du nått gränsen för antal postuppsättningar som tillåts i en DNS-zon? Det aktuella antalet postuppsättningar och det maximala antalet postuppsättningar visas i Azure Portal under ”Egenskaper” för zonen. Om du har nått den här gränsen tar du antingen bort några postuppsättningar eller kontaktar Azure Support för att höja gränsen för postuppsättningen för den här zonen och försök sedan igen.

Jag kan inte matcha min DNS-post

DNS-namnmatchningen är en process i flera steg som kan misslyckas av flera orsaker. Följande steg hjälper dig att undersöka varför DNS-matchningen inte fungerar för en DNS-post i en zon som finns i Azure DNS.

  1. Kontrollera att DNS-posterna är korrekt konfigurerade i Azure DNS. Granska DNS-posterna i Azure Portal och kontrollera att zonnamn, postnamn samt posttyp är korrekta.
  2. Kontrollera att DNS-posterna matchas korrekt på Azure DNS-namnservrarna.
    • Om du skapar DNS-frågor från din lokala dator, kan cachelagrade resultat visas som inte motsvarar det aktuella tillståndet för namnservrarna. Företagsnätverk använder dessutom ofta DNS-proxyservrar, vilket förhindrar att DNS-frågor dirigeras till specifika namnservrar. Undvik dessa problem genom att använda en webbaserad namnmatchningstjänst som t.ex. digwebinterface.
    • Se till att ange rätt namnservrar för DNS-zonen, enligt det som visas i Azure Portal.
    • Kontrollera att DNS-namnet är korrekt (du måste ange det fullständiga namnet, inklusive zonnamnet) och att posttypen stämmer
  3. Bekräfta att DNS-domännamnet är korrekt delegerat till Azure DNS-namnservrarna. Det finns många tredjeparts webbplatser som erbjuder DNS-delegeringsverifiering. Det här testet är ett zondelegeringstest, så du bör bara ange DNS-zonens namn och inte det fullständiga postnamnet.
  4. När du har utfört ovanstående bör DNS-posten matchas korrekt. Om du vill kontrollera detta använder du digwebinterface igen, men nu med standardinställningarna för namnservern.

Status för DNS-zon och scenarier med felaktig delegering

Status för DNS-zonen anger zonens aktuella status. DNS-zonstatus kan vara Okänd, Tillgänglig och Degraderad.

Okänt

När en resurs har skapats nyligen är hälsosignaler för dessa nya resurser inte tillgängliga omedelbart. Högst 24 timmar kan passera för att få rätt hälsosignaler för DNS-zoner. Fram till den här tiden visas hälsotillståndet för DNS-zonerna som Okänd.

När resurshälsokontrollen inte har tagit emot information om DNS-zoner på mer än 6 timmar markeras zonerna som Okända. Även om den här statusen inte är en slutgiltig indikation på resursens tillstånd är det en viktig datapunkt i felsökningsprocessen. När signalen tas emot och resursen körs som förväntat ändras resursens status till Tillgänglig efter några minuter.

Följande skärmbild är ett exempel på hälsokontrollmeddelandet för resursen.

Screenshot of unknown status.

Tillgängligt

En tillgänglig status anger att resurshälsokontrollen inte har identifierat något delegeringsproblem med dina DNS-zoner. Den här statusen innebär att NS-delegeringsposter underhålls korrekt i din primära zon och att poster som är avsedda för underordnade zoner inte finns i din primära zon.

Följande skärmbild är ett exempel på hälsokontrollmeddelandet för resursen.

Screenshot of available status.

Degraderad

En degraderad status anger att resurshälsokontrollen har identifierat ett delegeringsproblem med dina DNS-zoner. Korrigera delegeringskonfigurationen och vänta 24 timmar innan statusen ändras till Tillgänglig.

Följande skärmbild är ett exempel på hälsokontrollmeddelandet för resursen.

Screenshot of degraded status.

Om 24 timmar har gått efter att konfigurationen har korrigerats och DNS-zonerna fortfarande har degraderats kontaktar du supporten.

Scenario för konfigurationsfel

Följande scenario visar var ett konfigurationsfel har lett till dns-zonernas felaktiga tillstånd.

Felaktig delegering

En primär zon innehåller NS-delegeringsposter som hjälper till att delegera trafik från den primära till de underordnade zonerna. Om någon NS-delegeringspost finns i den överordnade zonen ska DNS-servern maskera alla andra poster under NS-delegeringsposten (förutom limposter) och dirigera trafik till respektive underordnade zon baserat på användarfrågan. Om en överordnad zon innehåller andra poster avsedda för de underordnade zonerna (delegerade zoner) under NS-delegeringsposten markeras zonen som felaktig och dess status är Degraderad.

Vad är limposter? – Det här är poster under delegeringsposten, som hjälper till att dirigera trafik till delegerade/underordnade zoner med hjälp av deras IP-adresser och konfigureras enligt följande.

Inställning Värde
Zon contoso.com
Delegeringspost Underordnade NS-ns1.child.contoso.com
Limma post ns1.child A 1.1.1.1

Exempel på en zon med feltillstånd

Följande är ett exempel på en zon som innehåller poster under NS-delegering.

  • Zonnamn: contoso.com
Namn Type TTL Värde
@ NS 3600 ns1-04.azure-dns.com.
@ SOA 3600 SOA-värden
* A 3600 255.255.255.255
Barn NS 3600 ns1-08.azure-dns.com (NS-delegeringspost)
foo.child A 3600 10.10.10.10
txt.child TXT 3600 "textpost"
abc.test A 3600 5.5.5.5

I föregående exempel är underordnade NS-delegeringsposter. Posterna foo.child och txt.child är poster som endast ska finnas i den underordnade zonen, child.contoso.com. Dessa poster kan orsaka inkonsekvenser om de inte tas bort från den överordnade zonen, contoso.com. Dessa inkonsekvenser kan leda till att zonen betraktas som inte felfri med statusen Degraderad .

Exempel på när en zon anses vara felfri eller inte felfri

Exempel Status
Zonen innehåller inte NS-delegeringsposter, limma poster och andra poster. Friska
Zonen innehåller endast NS-delegeringsposter. Friska
Zonen innehåller endast NS-delegeringsposter och limma poster. Friska
Zonen innehåller NS-delegeringsposter och andra poster (förutom limposter) under delegeringsposten, som ska finnas i den underordnade zonen. Ohälsosamma
Zonen innehåller NS-delegeringsposter, limma poster och andra poster (förutom limposter). Ohälsosamma

Hur kan du åtgärda det? – Lös problemet genom att leta upp och ta bort alla poster utom limma poster under NS-delegeringsposter i den överordnade zonen.

Så här hittar du feltillståndsdelegeringsposter? – Ett skript tillhandahålls för att hitta de felaktiga delegeringsposterna i din zon. Skriptet rapporterar poster som inte är felfria.

  1. Spara skriptet som finns på: Hitta felaktiga DNS-poster i Azure DNS – PowerShell-skriptexempel

  2. Kör skriptet enligt beskrivningen i skriptredigeraren. Skript kan redigeras för att uppfylla dina krav.

Historisk information – Du kan komma åt upp till 14 dagars hälsohistorik i avsnittet hälsohistorik för resurshälsa. Det här avsnittet innehåller också orsaken till stilleståndstiden (när det är tillgängligt) för de stilleståndstider som rapporteras av resurshälsan. För närvarande visar Azure stilleståndstiden för din DNS-zonresurs med en kornighet på 24 timmar.

Hur anger jag ”tjänst” och ”protokoll” för en SRV-post?

Azure DNS hanterar DNS-poster som postuppsättningar, vilket är en samling av poster med samma namn och av samma typ. För en SRV-postuppsättning måste ”tjänst” och ”protokoll” anges som en del av namnet på postuppsättningen. Andra SRV-parametrar (”prioritet”, ”vikt”, ”port” och ”mål”) anges separat för varje post i postuppsättningen.

Exempel på SRV-postnamn (tjänstnamn ”sip”, protokoll ”tcp”):

  • _sip._tcp (skapar en postuppsättning i zonex)
  • _sip._tcp.sipservice (skapar en postuppsättning med namnet "sipservice")

Nästa steg