Overzicht van privé-DNS-records

Artikel
02/07/2024

Dit artikel bevat informatie over ondersteuning voor DNS-records in Azure Privé-DNS zones. Zie voor een overzicht van privé-DNS-zones: Wat is een Azure Privé-DNS-zone?

DNS-records

Recordnamen

Records worden opgegeven met behulp van relatieve namen. Een FQDN-domeinnaam (Fully Qualified Domain Name) bevat de zonenaam, terwijl een relatieve naam deze niet bevat. 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 Privé-DNS ondersteunt de volgende algemene DNS-recordtypen: A, AAAA, CNAME, MX, PTR, SOA, SRV en TXT.

Notitie

Het hostveld in de SOA-record kan niet worden bewerkt.

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. Dit is een voorbeeld van een recordset:

www.contoso.com.        3600    IN    A    10.10.1.5
www.contoso.com.        3600    IN    A    10.10.1.10

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 hier worden weergegeven, waarin een recordset meer dan één record bevat, zijn echter niet ongewoon.

Stel dat u al een A-record 'www' hebt gemaakt in de zone 'contoso.com', die verwijst naar het IP-adres '10.10.1.5' (de eerste record die eerder werd weergegeven). 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 vorige 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-wildcardrecordset. 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'.

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.

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.

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 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).

* Ondersteuning voor 4096 tekens is momenteel alleen beschikbaar in de openbare Azure-cloud. Nationale clouds zijn beperkt tot 1024 tekens totdat de implementatie van 4k-ondersteuning is voltooid.

Tags en metagegevens

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 bij het gebruik van Azure Privé-DNS:

Persoonlijke DNS-zones

Bron	Limiet
Privé-DNS-zones per abonnement	1000
Recordsets per privé-DNS-zone	25.000
Records per recordset voor privé-DNS-zones	20
Virtual Network-koppelingen per privé-DNS-zone	1000
Koppelingen van virtuele netwerken per privé-DNS-zones waarvoor automatische registratie is ingeschakeld	100
Aantal privé-DNS-zones waaraan een virtueel netwerk kan worden gekoppeld met automatische registratie ingeschakeld	1
Aantal privé-DNS-zones in een virtueel netwerk dat kan worden gekoppeld	1000

Share via