Översikt över DNS-zoner och -poster

Den här artikeln beskriver viktiga begrepp för domäner, DNS-zoner, DNS-poster och postuppsättningar. Du får lära dig hur det stöds i Azure DNS.

Domännamn

Domain Name System är en hierarki av domäner. Hierarkin startar från rotdomänen, vars namn är ”.”. Under detta kommer toppdomänerna, till exempel ”com”, ”net”, ”org”, ”se” eller ”uk”. Under toppnivådomänerna finns domäner på andra nivån, till exempel "org.uk" eller "co.jp". Domänerna i DNS-hierarkin distribueras globalt och hanteras av DNS-namnservrar runt om i världen.

En domännamnsregistrator är en organisation som gör att du kan köpa ett domännamn, till exempel contoso.com. Genom att köpa ett domännamn får du rätt att styra DNS-hierarkin under det namnet, till exempel så att du kan dirigera namnet www.contoso.com till företagets webbplats. Registratorn kan vara värd för domänen på sina egna namnservrar för din räkning, eller så kan du ange alternativa namnservrar.

Azure DNS tillhandahåller en globalt distribuerad namnserverinfrastruktur med hög tillgänglighet som du kan använda som värd för din domän. Genom att vara värd för dina domäner i Azure DNS kan du hantera dina DNS-poster med samma autentiseringsuppgifter, API:er, verktyg, fakturering och support som dina andra Azure-tjänster.

Azure DNS stöder för närvarande inte köp av domännamn. Om du vill köpa ett domännamn måste du använda en domännamnsregistrator från tredje part. Registratorn tar vanligtvis ut en liten årlig avgift. Domänerna kan sedan finnas i Azure DNS för hantering av DNS-poster. Mer information finns i Delegera en domän till Azure DNS.

DNS-zoner

En DNS-zon används som värd åt DNS-posterna för en viss domän. Om du vill låta Azure DNS vara värd för din domän så måste du skapa en DNS-zon för det domännamnet. Varje DNS-post för din domän skapas sedan i den här DNS-zonen.

Domänen contoso.com kan t.ex. innehålla flera DNS-poster, som mail.contoso.com (för en e-postserver) och www.contoso.com (för en webbplats).

När du skapar en DNS-zon i Azure DNS:

  • Namnet på zonen måste vara unikt inom resursgruppen och zonen får inte redan finnas. Annars misslyckas åtgärden.
  • Samma zonnamn kan återanvändas i en annan resursgrupp eller Azure-prenumeration.
  • Om flera zoner som delar samma namn, tilldelas varje instans sin egen namnserveradress. Endast en uppsättning adresser kan konfigureras hos domänamnsregistratorn.

Anteckning

Du behöver inte äga ett domännamn för att kunna skapa en DNS-zon med det domännamnet i Azure DNS. Du måste dock äga domänen för att kunna konfigurera Azure DNS-namnservrarna som rätt namnservrar för domännamnet hos domännamnsregistratorn.

Mer information finns i Delegera en domän till Azure DNS.

DNS-poster

Registrera namn

DNS-poster i Azure anges med relativa namn. Ett fullständigt kvalificerat domännamn (FQDN), inkluderar zonnamnet, medan ett relativt namn inte gör det. Det relativa postnamnet www i zonen contoso.com ger till exempel det fullständigt kvalificerade postnamnet www.contoso.com.

En topppost är en DNS-post vid roten (eller toppen) av en DNS-zon. I DNS-zonen contoso.comhar till exempel en apex-post också det fullständigt kvalificerade namnet contoso.com (detta kallas ibland för en naken domän). Enligt konventionen används det relativa namnet '@' för att representera topposter.

Typer av poster

Varje DNS-post har ett namn och en typ. Posterna är indelade i olika typer beroende på den data de innehåller. Den vanligaste typen är en ”A”-post som mappar ett namn till en IPv4-adress. En annan vanlig typ är en ”MX”-post som mappar ett namn till en e-postserver.

Azure DNS stöder alla vanliga DNS-posttyper: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV och TXT. Observera att SPF-poster representeras med hjälp av TXT-poster.

Postuppsättningar

Ibland måste du skapa fler än en DNS-post av ett visst namn och typ. Anta exempelvis att webbplatsen ”www.contoso.com” finns på två olika IP-adresser. Webbplatsen kräver då två olika A-poster, en för varje IP-adress. Här är ett exempel på en postuppsättning:

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

Azure DNS hanterar DNS-poster med hjälp av postuppsättningar. En postuppsättning (även kallat en resurspostuppsättning)är en samling DNS-poster i en zon som har samma namn och är av samma typ. De flesta postuppsättningar innehåller en enda post. Men exempel som det ovanstående, där en postuppsättning innehåller fler än en post, är inte ovanliga.

Anta till exempel att du redan har skapat en A-post "www" i zonen "contoso.com" som pekar på IP-adressen ”134.170.185.46” (första posten ovan). För att skapa den andra posten skulle du lägga till posten i den befintliga postuppsättningen i stället för att skapa ytterligare en post.

Postuppsättningarna SOA och CNAME är undantag. DNS-standarden tillåter inte flera poster med samma namn för dessa typer, därför kan dessa postuppsättningar endast innehålla en enda post.

Time-to-live

Tid att leva, eller TTL, anger hur länge varje post cachelagras av klienter innan den skickas om. I exemplet ovan är TTL 3600 sekunder eller 1 timme.

I Azure DNS anges TTL för postuppsättningen, inte för varje post, så samma värde används för alla poster inom den postuppsättningen. Du kan ange valfritt TTL-värde mellan 1 och 2 147 483 647 sekunder.

Jokerteckenposter

Azure DNS stöder poster med jokertecken. Jokerteckenposter returneras som svar på en fråga med ett matchande namn, såvida det inte finns en närmare matchning från en postuppsättning som inte är jokertecken. Azure DNS stöder jokerteckenpostuppsättningar för alla posttyper utom NS och SOA.

Om du vill skapa en postuppsättning med jokertecken använder du postuppsättningens namn *. Du kan också använda ett namn med *som den vänstra etiketten, till exempel *.foo.

CAA-poster

MED CAA-poster kan domänägare ange vilka certifikatutfärdare som har behörighet att utfärda certifikat för sin domän. Med den här posten kan certifikatutfärdare undvika felutfärdande certifikat under vissa omständigheter. CAA-poster har tre egenskaper:

  • Flaggor: Det här fältet är ett heltal mellan 0 och 255 som används för att representera den kritiska flagga som har särskild betydelse per RFC
  • Tagg: en ASCII-sträng som kan vara något av följande:
    • problem: om du vill ange certifikatutfärdare som tillåts utfärda certifikat (alla typer)
    • issuewild: om du vill ange certifikatutfärdare som tillåts utfärda certifikat (endast jokerteckencertifikat)
    • iodef: ange en e-postadress eller ett värdnamn som certifikatutfärdare kan meddela om obehöriga certifikatbegäranden
  • Värde: värdet för den specifika tagg som valts

CNAME-poster

CNAME-postuppsättningar kan inte samexistera med andra postuppsättningar med samma namn. Du kan till exempel inte skapa en CNAME-postuppsättning med det relativa namnet "www" och en A-post med det relativa namnet "www" samtidigt.

Eftersom zon-apex (namn = '@') alltid innehåller NS- och SOA-postuppsättningarna när zonen skapas kan du inte skapa en CNAME-postuppsättning i zonexeppet.

Den här begränsningarna kommer sig av DNS-standarderna och är inte begränsningar i Azure DNS.

NS-poster

NS-posten som anges i zon-apex (namnet '@') skapas automatiskt med varje DNS-zon och tas bort automatiskt när zonen tas bort. Det går inte att ta bort den separat.

Den här postuppsättningen innehåller namnen på de Azure DNS-namnservrar som tilldelats till zonen. Du kan lägga till fler namnservrar i den här NS-postuppsättningen för att stödja cohosting-domäner med mer än en DNS-provider. Du kan också ändra TTL och metadata för den här postuppsättningen. Det är dock inte tillåtet att ta bort eller ändra de i förväg ifyllda Azure DNS-namnservrarna.

Den här begränsningen gäller endast för NS-posten som angetts i zon-apex. Andra NS-postuppsättningar i din zon (som används för att delegera underordnade zoner) kan skapas, ändras och tas bort utan begränsningar.

SOA-poster

En SOA-postuppsättning skapas automatiskt i toppen av varje zon (namn = @) och tas bort automatiskt när zonen tas bort. SOA-poster kan inte skapas eller tas bort separat.

Du kan ändra alla egenskaper för SOA-posten förutom egenskapen "värd". Den här egenskapen förkonfigureras för att referera till det primära namnservernamnet som tillhandahålls av Azure DNS.

Zonserienumret i SOA-posten uppdateras inte automatiskt när ändringar görs i posterna i zonen. Den kan uppdateras manuellt genom att redigera SOA-posten om det behövs.

SPF-poster

SPF-poster (Sender Policy Framework) används för att ange vilka e-postservrar som kan skicka e-post för ett domännamns räkning. Rätt konfiguration av SPF-poster är viktigt för att förhindra mottagare från att markera din e-post som skräppost.

DNS-RFC:erna introducerade ursprungligen en ny SPF-posttyp som stöd för det här scenariot. För att stödja äldre namnservrar tillät de också användning av TXT-posttypen för att ange SPF-poster. Denna tvetydighet ledde till förvirring, som löstes av RFC 7208. Den anger att SPF-poster måste skapas med hjälp av TXT-posttypen. Det står också att SPF-posttypen är inaktuell.

SPF-poster stöds av Azure DNS och måste skapas med hjälp av TXT-posttypen. Den föråldrade SPF-posttypen stöds inte. När du importerar en DNS-zonfil konverteras alla SPF-poster som använder SPF-posttypen till TXT-posttypen.

SRV-poster

SRV-poster används av olika tjänster för att ange serverplatser. När du anger en SRV-post i Azure DNS:

  • Tjänsten och protokollet måste anges som en del av postuppsättningens namn, med prefixet understreck. Till exempel "_sip._tcp.name". För en post i zonapex behöver du inte ange @i postnamnet. Använd bara tjänsten och protokollet, till exempel "_sip._tcp".
  • Prioritet, vikt, port och mål anges som parametrar för varje post i postuppsättningen.

TXT-poster

TXT-poster används för att mappa domännamn till godtyckliga textsträngar. De används i flera program, särskilt relaterade till e-postkonfiguration, till exempel SPF (Sender Policy Framework) och DomainKeys Identified Mail (DKIM)..

DNS-standarderna tillåter att en enda TXT-post innehåller flera strängar, som var och en kan innehålla upp till 255 tecken. När flera strängar används sammanfogas de av klienter och behandlas som en enda sträng.

När du anropar Azure DNS REST API måste du ange varje TXT-sträng separat. När du använder Azure Portal, PowerShell eller CLI-gränssnitt bör du ange en enskild sträng per post, som automatiskt delas in i segment med 255 tecken om det behövs.

Flera strängar i en DNS-post bör inte förväxlas med flera TXT-poster i en TXT-postuppsättning. En TXT-postuppsättning kan innehålla flera poster , som var och en kan innehålla flera strängar. Azure DNS stöder en total stränglängd på upp till 1 024 tecken i varje TXT-postuppsättning (för alla poster tillsammans).

Taggar och metadata

Taggar

Taggar är en lista över namn/värde-par och används av Azure Resource Manager för att märka resurser. Azure Resource Manager använder taggar för att aktivera filtrerade vyer av din Azure-faktura och du kan även ange en princip för vissa taggar. Mer information om taggar finns i Ordna dina Azure-resurser med hjälp av taggar.

Azure DNS stöder användning av Azure Resource Manager-taggar på DNS-zonresurser. Det stöder inte taggar på DNS-postuppsättningar, men eftersom alternativa metadata stöds på DNS-postuppsättningar enligt beskrivningen nedan.

Metadata

Som ett alternativ till postuppsättningstaggar har Azure DNS stöd för att kommentera postuppsättningar med "metadata". På samma sätt som med taggar kan du med metadata associera namn/värde-par med varje postuppsättning. Den här funktionen kan vara användbar, till exempel för att registrera syftet med varje postuppsättning. Till skillnad från taggar kan metadata inte användas för att tillhandahålla en filtrerad vy av din Azure-faktura och kan inte anges i en Azure Resource Manager-princip.

Etags

Anta att två personer eller två processer försöker ändra en DNS-post samtidigt. Vilken vinner? Och vet vinnaren att de har skrivit över ändringar som skapats av någon annan?

Azure DNS använder Etags för att hantera samtidiga ändringar av samma resurs på ett säkert sätt. Etags är separata från Azure Resource Manager "Taggar". Varje DNS-resurs (zon eller postuppsättning) har en Etag associerad med den. När en resurs hämtas hämtas även dess Etag. När du uppdaterar en resurs kan du välja att skicka tillbaka Etag så att Azure DNS kan verifiera att Etag på servern matchar. Eftersom varje uppdatering av en resurs resulterar i att Etag återskapas, indikerar ett Etag-matchningsfel att en samtidig ändring har inträffat. Etags kan också användas när du skapar en ny resurs för att säkerställa att resursen inte redan finns.

Som standard använder Azure DNS PowerShell Etags för att blockera samtidiga ändringar i zoner och postuppsättningar. Den valfria växeln -Overwrite kan användas för att undertrycka Etag-kontroller, i vilket fall eventuella samtidiga ändringar som har inträffat skrivs över.

På nivån för Azure DNS REST API anges Etags med hjälp av HTTP-huvuden. Beteendet anges i följande tabell:

Huvud Beteende
Ingen PUT lyckas alltid (inga Etag-kontroller)
If-match <etag> PUT lyckas bara om resursen finns och Etag matchar
If-match * PUT lyckas bara om resursen finns
If-none-match * PUT lyckas bara om resursen inte finns

Gränser

Följande standardgränser gäller när du använder Azure DNS:

Offentliga DNS-zoner

Resurs Gräns
Offentliga DNS-zoner per prenumeration 250 1
Postuppsättningar per offentlig DNS-zon 10 000 1
Poster per post som angetts i offentlig DNS-zon 20
Antal aliasposter för en enskild Azure-resurs 20

1 Om du behöver öka dessa gränser kontaktar du Azure-supporten.

Privat DNS zoner

Resurs Gräns
Privat DNS zoner per prenumeration 1000
Postuppsättningar per privat DNS-zon 25000
Poster per postuppsättning för privata DNS-zoner 20
Virtual Network länkar per privat DNS-zon 1000
Virtual Networks-länkar per privat DNS-zoner med automatisk registrering aktiverat 100
Antal privata DNS-zoner som ett virtuellt nätverk kan länkas till med automatisk registrering aktiverat 1
Antal privata DNS-zoner som ett virtuellt nätverk kan länkas till 1000
Antal DNS-frågor som en virtuell dator kan skicka till Azure DNS-matchare per sekund 1000 1
Maximalt antal DNS-frågor i kö (väntande svar) per virtuell dator 200 1

1 Dessa gränser tillämpas på varje enskild virtuell dator och inte på den virtuella nätverksnivån. DNS-frågor som överskrider dessa gränser tas bort.

Nästa steg