Overzicht van DNS-zones en -records

In dit artikel worden de belangrijkste concepten van domeinen, DNS-zones, DNS-records en DNS-recordsets uitgelegd. U leert hoe ze worden ondersteund in Azure DNS.

Domeinnamen

Het Domain Name System is een hiërarchie van domeinen. De hiërarchie begint vanaf het domein, waarvan de root naam simpelweg '.' is. Daaronder komen domeinen op het hoogste niveau, zoals com, net, orgof uk jp. Onder de domeinen op het hoogste niveau bevinden zich domeinen op het tweede niveau, zoals org.uk of co.jp. De domeinen in de DNS-hiërarchie worden wereldwijd gedistribueerd, gehost door DNS-naamservers over de hele wereld.

Een domeinnaamregistrar is een organisatie waarmee u een domeinnaam kunt kopen, zoals contoso.com. Als u een domeinnaam aanschaft, hebt u het recht om de DNS-hiërarchie onder die naam te beheren, bijvoorbeeld om de naam www.contoso.com naar uw bedrijfswebsite te leiden. De registrar kan namens u het domein hosten op eigen naamservers of u toestaan alternatieve naamservers op te geven.

Azure DNS biedt een wereldwijd gedistribueerde en hoge beschikbaarheidsserverinfrastructuur die u kunt gebruiken om uw domein te hosten. Door uw domeinen in Azure DNS te hosten, kunt u uw DNS-records beheren met dezelfde referenties, API's, hulpprogramma's, facturering en ondersteuning als uw andere Azure-services.

Azure DNS biedt momenteel geen ondersteuning voor het aanschaffen van domeinnamen. Tegen een jaarlijkse vergoeding kunt u een domeinnaam kopen met behulp van App Service-domeinen of bij een externe domeinnaamregistrar. Uw domeinen kunnen vervolgens worden gehost in Azure DNS voor recordbeheer. Zie Delegate a domain to Azure DNS (Een domein aan Azure DNS overdragen) voor meer informatie.

DNS-zones

Een DNS-zone wordt gebruikt voor het hosten van de DNS-records voor een specifiek domein. Als u uw domein wilt hosten in Azure DNS, moet u een DNS-zone maken voor die domeinnaam. Alle DNS-records voor uw domein worden vervolgens gemaakt binnen deze DNS-zone.

Het domein contoso.com kan bijvoorbeeld een aantal DNS-records bevatten, zoals mail.contoso.com (voor een e-mailserver) en www.contoso.com (voor een website).

Bij het maken van een DNS-zone in Azure DNS:

• De naam van de zone moet uniek zijn binnen de resourcegroep en de zone mag niet al bestaan. Anders mislukt de bewerking.
• Dezelfde zonenaam kan opnieuw worden gebruikt in een andere resourcegroep of in een ander Azure-abonnement.
• Als meerdere zones dezelfde naam delen, wordt aan elk exemplaar een ander naamserveradres toegewezen. Er kan bij de domeinnaamregistrar slechts één set adressen worden geconfigureerd.

Notitie

U hoeft niet de eigenaar van een domeinnaam te zijn om een DNS-zone met die domeinnaam in Azure DNS te maken. U moet echter wel de eigenaar van het domein zijn om de Azure DNS-naamservers bij de domeinnaamregistrar te configureren als de juiste naamservers voor de domeinnaam.

Zie Delegate a domain to Azure DNS (Een domein aan Azure DNS overdragen) voor meer informatie.

DNS-records

Recordnamen

In Azure DNS worden records opgegeven met behulp van relatieve namen. Een FQDN (Fully Qualified Domain Name) bevat de zonenaam, terwijl een relatieve naam dat niet doet. De relatieve recordnaam www in de zone contoso.com geeft bijvoorbeeld de volledig gekwalificeerde recordnaam www.contoso.com.

Een apexrecord is een DNS-record in de hoofdmap (of apex) van een DNS-zone. In de DNS-zone contoso.comheeft een apex-record bijvoorbeeld ook de volledig gekwalificeerde naam contoso.com (dit wordt ook wel een naakt domein genoemd). Volgens de conventies wordt de relatieve naam '@' gebruikt om apexrecords te representeren.

Recordtypen

Elke DNS-record heeft een naam en een type. Records zijn ingedeeld in verschillende typen overeenkomstig de gegevens die ze bevatten. Het meest voorkomende type is een A-record, waarmee een naam aan een IPv4-adres wordt toegewezen. Een ander algemeen type is een MX-record, waarmee een naam aan een e-mailserver wordt toegewezen.

Azure DNS ondersteunt alle algemene DNS-recordtypen: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV en TXT. Houd er rekening mee dat SPF-records worden gerepresenteerd door TXT-records.

Aanvullende recordtypen worden ondersteund als de zone is ondertekend met DNS-beveiligingsextensies (DNSSEC), zoals DS-delegering (DS) en TLSA-bronrecords (Transport Layer Security Authentication).

DNSSEC-bronrecordtypen, zoals DNSKEY, RRSIG en NSEC3-records, worden automatisch toegevoegd wanneer een zone is ondertekend met DNSSEC. Deze typen DNSSEC-resourcerecords kunnen niet worden gemaakt of gewijzigd na het ondertekenen van de zone.

Recordsets

Soms moet u meer dan één DNS-record maken met een bepaalde naam en een bepaald type. Stel bijvoorbeeld dat de website www.contoso.com wordt gehost op twee verschillende IP-adressen. De website vereist twee verschillende A-records, één voor elk IP-adres. Hier volgt een voorbeeld van een recordset:

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

Azure DNS beheert alle DNS-records met recordsets. Een recordset (ook bekend als een resource-recordset) is een verzameling DNS-records in een zone die dezelfde naam hebben en van hetzelfde type zijn. De meeste recordsets bevatten één record. Voorbeelden zoals hierboven, waarin een recordset meer dan één record bevat, zijn echter niet ongewoon.

Veronderstel bijvoorbeeld dat u al een A-record 'www' hebt gemaakt in de zone 'contoso.com' die naar het IP-adres '134.170.185.46' verwijst (de eerste record bovenaan). Als u nu de tweede record wilt maken, moet u deze toevoegen aan de bestaande recordset. U maakt dus geen aanvullende recordset.

De recordtypen SOA en CNAME zijn uitzonderingen. De DNS-standaarden staan voor deze typen niet toe dat er meerdere records zijn met dezelfde naam. Daarom kunnen deze recordsets slechts één record bevatten.

Time-to-live

De time to live, of TTL, geeft aan hoe lang elke record in de cache wordt opgeslagen door clients voordat er query's worden uitgevoerd. In het bovenstaande voorbeeld is de TTL 3600 seconden of 1 uur.

In Azure DNS wordt de TTL opgegeven voor de recordset, niet voor elke record, dus dezelfde waarde wordt gebruikt voor alle records in die recordset. U kunt een TTL-waarde tussen 1 en 2.147.483.647 seconden opgeven.

Records met jokertekens

Azure DNS ondersteunt recordsets met jokertekens. Jokertekenrecords worden geretourneerd als reactie op een query met een overeenkomende naam, tenzij er een dichtere overeenkomst is van een niet-jokertekenset. Azure DNS ondersteunt jokertekenrecordsets voor alle recordtypen, behalve NS en SOA.

Als u een recordset met jokertekens wilt maken, gebruikt u de naam van de recordset *. U kunt ook een naam met '*' gebruiken als het meest linkse label, bijvoorbeeld '*.foo'.

CAA-records

MET CAA-records kunnen domeineigenaren opgeven welke certificeringsinstanties (CA's) gemachtigd zijn om certificaten voor hun domein uit te geven. Met deze record kunnen CA's in sommige gevallen verkeerd verlenende certificaten voorkomen. CAA-records hebben drie eigenschappen:

• Vlaggen: Dit veld is een geheel getal tussen 0 en 255, dat wordt gebruikt om de kritieke vlag weer te geven die speciale betekenis heeft per RFC6844
• Tag: een ASCII-tekenreeks die een van de volgende opties kan zijn:
  • probleem: als u CA's wilt opgeven die zijn toegestaan certificaten uit te geven (alle typen)
  • issuewild: als u CA's wilt opgeven die certificaten mogen uitgeven (alleen jokertekens)
  • iodef: geef een e-mailadres of hostnaam op waarnaar CA's kunnen waarschuwen voor aanvragen voor problemen met niet-geautoriseerde certificaten
• Waarde: de waarde voor de specifieke tag die is gekozen

CNAME-records

CNAME-recordsets kunnen niet naast andere recordsets met dezelfde naam bestaan. U kunt bijvoorbeeld geen CNAME-recordset maken met de relatieve naam www en een A-record met de relatieve naam www tegelijk.

Omdat de zone-apex (name = '@') altijd de NS- en SOA-recordsets bevat tijdens het maken van de zone, kunt u geen CNAME-recordset maken in de zone-apex.

Deze beperkingen worden veroorzaakt door de DNS-standaarden en zijn geen beperkingen van Azure DNS.

NS-records

De NS-recordset in de zone-apex (naam '@') wordt automatisch gemaakt met elke DNS-zone en wordt automatisch verwijderd wanneer de zone wordt verwijderd. Het kan niet afzonderlijk worden verwijderd.

Deze recordset bevat de namen van de Azure DNS-naamservers die zijn toegewezen aan de zone. U kunt meer naamservers toevoegen aan deze NS-recordset om cohostingdomeinen met meer dan één DNS-provider te ondersteunen. U kunt ook de TTL en metagegevens voor deze recordset wijzigen. Het verwijderen of wijzigen van de vooraf ingevulde Azure DNS-naamservers is echter niet toegestaan.

Deze beperking geldt alleen voor de NS-recordset in de zone-apex. Andere NS-recordsets in uw zone (zoals gebruikt voor het delegeren van onderliggende zones) kunnen zonder beperking worden gemaakt, gewijzigd en verwijderd.

SOA-records

Er wordt automatisch een SOA-recordset gemaakt in de apex van elke zone (naam = '@' ) en wordt automatisch verwijderd wanneer de zone wordt verwijderd. SOA-records kunnen niet afzonderlijk worden gemaakt of verwijderd.

U kunt alle eigenschappen van de SOA-record wijzigen, met uitzondering van de host eigenschap. Deze eigenschap wordt vooraf geconfigureerd om te verwijzen naar de naam van de primaire naamserver die is opgegeven door Azure DNS.

Het serienummer van de zone in de SOA-record wordt niet automatisch bijgewerkt wanneer er wijzigingen worden aangebracht in de records in de zone. U kunt deze indien nodig handmatig bijwerken door de SOA-record te bewerken.

Notitie

Azure DNS biedt momenteel geen ondersteuning voor het gebruik van een punt (.) vóór de '@' in de hostmasterpostvakvermelding soa. Bijvoorbeeld: john.smith@contoso.xyz (geconverteerd naar john.smith.contoso.xyz) en john\.smith@contoso.xyz zijn niet toegestaan.

SPF-records

SPF-records (Sender Policy Framework) worden gebruikt om op te geven welke e-mailservers e-mail namens een domeinnaam kunnen verzenden. De juiste configuratie van SPF-records is belangrijk om te voorkomen dat geadresseerden uw e-mail markeren als ongewenste e-mail.

De DNS-RFC's hebben oorspronkelijk een nieuw SPF-recordtype geïntroduceerd ter ondersteuning van dit scenario. Ter ondersteuning van oudere naamservers hebben ze ook het gebruik van het TXT-recordtype toegestaan om SPF-records op te geven. Deze dubbelzinnigheid leidde tot verwarring, die werd opgelost door RFC 7208. Er wordt aangegeven dat SPF-records moeten worden gemaakt met behulp van het TXT-recordtype. Ook wordt aangegeven dat het SPF-recordtype is afgeschaft.

SPF-records worden ondersteund door Azure DNS en moeten worden gemaakt met behulp van het TXT-recordtype. Het verouderde SPF-recordtype wordt niet ondersteund. Wanneer u een DNS-zonebestand importeert, worden alle SPF-records die gebruikmaken van het SPF-recordtype geconverteerd naar het TXT-recordtype.

SRV-records

SRV-records worden door verschillende services gebruikt om serverlocaties op te geven. Wanneer u een SRV-record opgeeft in Azure DNS:

• De service en het protocol moeten worden opgegeven als onderdeel van de naam van de recordset, voorafgegaan door onderstrepingstekens, zoals '_sip._tcp.name'. Voor een record in de zone-apex hoeft u geen @op te geven in de recordnaam, gewoon de service en het protocol gebruiken, zoals '_sip._tcp'.
• De prioriteit, het gewicht, de poort en het doel worden opgegeven als parameters van elke record in de recordset.

TXT-records

TXT-records worden gebruikt om domeinnamen toe te wijzen aan willekeurige teksttekenreeksen. Ze worden gebruikt in meerdere toepassingen, met name met betrekking tot e-mailconfiguratie, zoals het Sender Policy Framework (SPF) en DomainKeys Identified Mail (DKIM).

Met de DNS-standaarden kan één TXT-record meerdere tekenreeksen bevatten, die elk maximaal 255 tekens lang kunnen zijn. Wanneer meerdere tekenreeksen worden gebruikt, worden ze samengevoegd door clients en behandeld als één tekenreeks.

Wanneer u de Azure DNS REST API aanroept, moet u elke TXT-tekenreeks afzonderlijk opgeven. Wanneer u de Azure Portal-, PowerShell- of CLI-interfaces gebruikt, moet u één tekenreeks per record opgeven. Deze tekenreeks wordt indien nodig automatisch onderverdeeld in segmenten van 255 tekens.

De meerdere tekenreeksen in een DNS-record moeten niet worden verward met de meerdere TXT-records in een TXT-recordset. Een TXT-recordset kan meerdere records bevatten, die elk meerdere tekenreeksen kunnen bevatten. Azure DNS ondersteunt een totale tekenreekslengte van maximaal 4096 tekens in elke TXT-recordset (in alle records gecombineerd).

DS-records

De DS-record (delegatie ondertekenaar) is een DNSSEC-resourcerecordtype dat wordt gebruikt om een delegatie te beveiligen. Als u een DS-record in een zone wilt maken, moet de zone eerst worden ondertekend met DNSSEC.

TLSA-records

Een TLSA-record (Transport Layer Security Authentication) wordt gebruikt om een TLS-servercertificaat of openbare sleutel te koppelen aan de domeinnaam waar de record wordt gevonden. Een TLSA-record koppelt de openbare sleutel (een TLS-servercertificaat) aan de domeinnaam en biedt een extra beveiligingslaag voor TLS-verbindingen.

Als u TLSA-records effectief wilt gebruiken, moet DNSSEC zijn ingeschakeld voor uw domein. Dit zorgt ervoor dat de TLSA-records kunnen worden vertrouwd en correct kunnen worden gevalideerd

Tags en metagegevens

Tags

Tags zijn een lijst met naam-waardeparen en worden door Azure Resource Manager gebruikt om resources te labelen. Azure Resource Manager maakt gebruik van tags om gefilterde weergaven van uw Azure-factuur in te schakelen en stelt u ook in staat een beleid in te stellen voor bepaalde tags. Zie Tags gebruiken om uw Azure-resources te organiseren voor meer informatie over tags.

Azure DNS ondersteunt het gebruik van Azure Resource Manager-tags op DNS-zoneresources. Het biedt geen ondersteuning voor tags voor DNS-recordsets, hoewel metagegevens als alternatief worden ondersteund voor DNS-recordsets, zoals hieronder wordt uitgelegd.

Metagegevens

Als alternatief voor tags voor recordsets biedt Azure DNS ondersteuning voor het toevoegen van aantekeningen aan recordsets met behulp van metagegevens. Net als bij tags kunt u met metagegevens paren van naam-waarde koppelen aan elke recordset. Deze functie kan handig zijn, bijvoorbeeld om het doel van elke recordset vast te leggen. In tegenstelling tot tags kunnen metagegevens niet worden gebruikt om een gefilterde weergave van uw Azure-factuur te bieden en kunnen ze niet worden opgegeven in een Azure Resource Manager-beleid.

Etags

Stel dat twee personen of twee processen tegelijkertijd een DNS-record proberen te wijzigen. Welke wint? En weet de winnaar dat ze wijzigingen hebben overschreven die door iemand anders zijn gemaakt?

Azure DNS maakt gebruik van Etags om gelijktijdige wijzigingen in dezelfde resource veilig af te handelen. Etags zijn gescheiden van Azure Resource Manager -tags. Aan elke DNS-resource (zone of recordset) is een Etag gekoppeld. Wanneer een resource wordt opgehaald, wordt de bijbehorende Etag ook opgehaald. Wanneer u een resource bijwerkt, kunt u ervoor kiezen om de Etag door te geven, zodat Azure DNS de Etag op de serverovereenkomsten kan verifiëren. Omdat elke update van een resource resulteert in het opnieuw genereren van de Etag, geeft een niet-overeenkomende Etag aan dat er een gelijktijdige wijziging is opgetreden. Etags kunnen ook worden gebruikt bij het maken van een nieuwe resource om ervoor te zorgen dat de resource nog niet bestaat.

Azure DNS PowerShell maakt standaard gebruik van Etags om gelijktijdige wijzigingen in zones en recordsets te blokkeren. De optionele schakeloptie -Overschrijven kan worden gebruikt om Etag-controles te onderdrukken. In dat geval worden eventuele gelijktijdige wijzigingen die zijn opgetreden, overschreven.

Op het niveau van de Azure DNS REST API worden Etags opgegeven met behulp van HTTP-headers. Hun gedrag wordt gegeven in de volgende tabel:

Koptekst	Gedrag
Geen	PUT slaagt altijd (geen Etag-controles)
If-match <etag>	PUT slaagt alleen als de resource bestaat en Etag overeenkomt
If-match *	PUT slaagt alleen als de resource bestaat
If-none-match *	PUT slaagt alleen als de resource niet bestaat

Limieten

De volgende standaardlimieten zijn van toepassing wanneer u Azure DNS gebruikt:

Openbare DNS-zones

Bron	Limiet
Openbare DNS-zones per abonnement	250 1
Recordsets per openbare DNS-zone	10.000 1
Records per recordset in openbare DNS-zone	20
Aantal Alias-records voor een enkele Azure-resource	20

¹als u deze limieten wilt verhogen, neemt u contact op met ondersteuning voor Azure.

Volgende stappen

• Als u Azure DNS wilt gaan gebruiken, leert u hoe u een DNS-zone maakt en DNS-records maakt.
• Als u een bestaande DNS-zone wilt migreren, leert u hoe u een DNS-zonebestand importeert en exporteert.