Dela via

Översikt över DNS-zoner och -poster

  • Artikel

I den här artikeln beskrivs viktiga begrepp för domäner, DNS-zoner, DNS-poster och postuppsättningar. Du lär dig hur de stöds i Azure DNS.

Domännamn

Domain Name System är en hierarki av domäner. Hierarkin börjar från domänen root , vars namn helt enkelt är ".". Under detta kommer toppnivådomäner, till exempel com, net, orguk eller jp. 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 åt dig 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. För en årlig avgift så kan du köpa ett domännamn med hjälp av App Service-domäner eller en domännamnsregistrator från tredje part. Dina domäner kan sedan hanteras i Azure DNS för posthantering. Mer information finns i Delegera en domän till Azure DNS.

DNS-zoner

En DNS-zon används som värd för 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.

Kommentar

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

Poster i Azure DNS anges med relativa namn. Ett fullständigt domännamn (FQDN) innehåller 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 även 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.

Ytterligare posttyper stöds om zonen är signerad med DNS Security Extensions (DNSSEC), till exempel delegeringssignerare (DS) och TLSA-resursposter (Transport Layer Security Authentication).

DNSSEC-resursposttyper som DNSKEY, RRSIG och NSEC3-poster läggs till automatiskt när en zon signeras med DNSSEC. Dessa typer av DNSSEC-resursposter kan inte skapas eller ändras efter zonsignering.

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. Exempel som det ovan, där en postuppsättning innehåller mer än en post, är dock 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

Time to live, eller TTL, anger hur länge varje post cachelagras av klienter innan den efterfrågas. 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 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ättningsnamnet *. 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 RFC6844
  • 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 begäranden om obehöriga certifikatutfärdare
  • 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 zonexet.

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

NS-poster

NS-posten som anges vid zon-apex (namn '@') 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 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 förifyllda Azure DNS-namnservrarna.

Den här begränsningen gäller endast för NS-posten som angetts i zonexet. 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 host . 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.

Kommentar

Azure DNS stöder för närvarande inte användning av en punkt (.) före "@" i postlådan soa hostmaster. Till exempel: john.smith@contoso.xyz (konverteras till john.smith.contoso.xyz) och john\.smith@contoso.xyz tillåts inte.

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 att mottagarna markerar din e-post som skräppost.

DNS-RFC:erna introducerade ursprungligen en ny SPF-posttyp för att stödja 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. Det står 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, prefixet med understreck, till exempel "_sip._tcp.name". För en post i zonexemplet 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 enskild TXT-post innehåller flera strängar, som var och en kan vara upp till 255 tecken lång. Om 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 gränssnitten Azure Portal, PowerShell eller CLI bör du ange en enda sträng per post. Den här strängen delas automatiskt 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 4 096 tecken i varje TXT-postuppsättning (över alla poster tillsammans).

DS-poster

Posten delegeringssignerare (DS) är en DNSSEC-resursposttyp som används för att skydda en delegering. Om du vill skapa en DS-post i en zon måste zonen först signeras med DNSSEC.

TLSA-poster

En TLSA-post (Transport Layer Security Authentication) används för att associera ett TLS-servercertifikat eller en offentlig nyckel med domännamnet där posten hittas. En TLSA-post länkar den offentliga nyckeln (ett TLS-servercertifikat) till domännamnet, vilket ger ytterligare ett säkerhetslager för TLS-anslutningar.

Om du vill använda TLSA-poster effektivt måste DNSSEC vara aktiverat på din domän. Detta säkerställer att TLSA-posterna kan vara betrodda och korrekt verifierade

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 gör att du även kan 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 som ett alternativ stöds metadata 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 hjälp av metadata. Precis 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 över 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 förhindra 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. Deras beteende anges i följande tabell:

Header Funktionssätt
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

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

Nästa steg