Inleiding
DNS, of het Domain Name System, is vaak een erg moeilijk onderdeel bij het leren configureren van websites en servers. Het begrijpen van hoe DNS werkt zal u helpen bij het diagnosticeren van problemen met het configureren van toegang tot uw websites en zal u in staat stellen uw begrip van wat er achter de schermen gebeurt, te verbreden.
In deze gids zullen we enkele fundamentele DNS-concepten bespreken die u helpen snel van start te gaan met uw DNS-configuratie. Na het doorlopen van deze gids zou u klaar moeten zijn om uw domeinnaam in te stellen met DigitalOcean of uw eigen DNS-server in te stellen.
Voordat we ons storten op het opzetten van uw eigen servers om uw domein op te lossen of het opzetten van onze domeinen in het controlepaneel, laten we eerst enkele basisconcepten doornemen over hoe dit eigenlijk allemaal werkt.
Domeinterminologie
We moeten beginnen met het definiëren van onze termen. Hoewel sommige van deze onderwerpen bekend zijn uit andere contexten, worden er bij het praten over domeinnamen en DNS veel termen gebruikt die niet al te vaak worden gebruikt in andere gebieden van de informatica.
Laten we het makkelijk maken:
Domeinnaamsysteem
Het domeinnaamsysteem, vaker bekend als “DNS”, is het netwerksysteem dat ervoor zorgt dat we mensvriendelijke namen kunnen omzetten naar unieke IP-adressen.
Domeinnaam
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
De URL “google.com” is verbonden met de servers van Google Inc. Het domeinnaamsysteem stelt ons in staat om de Google-servers te bereiken wanneer we “google.com” in onze browsers typen.
IP-adres
Een IP-adres is wat we een netwerkadresbaar locatie noemen. Elk IP-adres moet uniek zijn binnen zijn netwerk. Als we het hebben over websites, is dit netwerk het hele internet.
IPv4, de meest voorkomende vorm van adressen, worden geschreven als vier sets getallen, waarbij elke set maximaal drie cijfers heeft en elke set gescheiden is door een punt. Bijvoorbeeld, “111.222.111.222” zou een geldig IPv4 IP-adres kunnen zijn. Met DNS koppelen we een naam aan dat adres, zodat je niet een ingewikkelde reeks getallen hoeft te onthouden voor elke plek die je op een netwerk wilt bezoeken.
Top-Level Domein
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
Top-level domeinen bevinden zich bovenaan in de hiërarchie wat betreft domeinnamen. Bepaalde partijen krijgen door ICANN (Internet Corporation for Assigned Names and Numbers) het beheer over top-level domeinen. Deze partijen kunnen vervolgens domeinnamen onder het TLD distribueren, meestal via een domeinregistrar.
Hosts
Binnen een domein kan de domeineigenaar individuele hosts definiëren, die verwijzen naar afzonderlijke computers of diensten die toegankelijk zijn via een domein. Bijvoorbeeld, de meeste domeineigenaren maken hun webservers toegankelijk via het kale domein (voorbeeld.com) en ook via de “host” definitie “www” (www.voorbeeld.com).
Je kunt andere hostdefinities hebben onder het algemene domein. Je zou bijvoorbeeld API-toegang kunnen hebben via een “api” host (api.voorbeeld.com) of je zou ftp-toegang kunnen hebben door een host genaamd “ftp” of “bestanden” te definiëren (ftp.voorbeeld.com of bestanden.voorbeeld.com). De hostnamen kunnen willekeurig zijn, zolang ze maar uniek zijn voor het domein.
Subdomein
A subject related to hosts are subdomains.
DNS werkt in een hiërarchie. TLD’s kunnen veel domeinen onder zich hebben. Bijvoorbeeld, de “com” TLD heeft zowel “google.com” als “ubuntu.com” eronder. Een “subdomein” verwijst naar elk domein dat deel uitmaakt van een groter domein. In dit geval kan “ubuntu.com” worden gezegd een subdomein te zijn van “com”. Dit wordt meestal gewoon het domein genoemd of het “ubuntu” gedeelte wordt een SLD genoemd, wat staat voor second level domain.
Op dezelfde manier kan elk domein “subdomeinen” controleren die eronder liggen. Dit is meestal wat we bedoelen met subdomeinen. Bijvoorbeeld, je zou een subdomein kunnen hebben voor de geschiedenisafdeling van je school op “www.geschiedenis.school.edu”. Het “geschiedenis” gedeelte is een subdomein.
Het verschil tussen een hostnaam en een subdomein is dat een host een computer of bron definieert, terwijl een subdomein het ouderdomein uitbreidt. Het is een methode om het domein zelf onder te verdelen.
Of het nu gaat om subdomeinen of hosts, je begint te zien dat de meest linkse delen van een domein het meest specifiek zijn. Dit is hoe DNS werkt: van meest naar minst specifiek terwijl je van links naar rechts leest.
Volledig gekwalificeerde domeinnaam
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
Dit betekent dat het elke bovenliggende domein specificeert, inclusief de TLD. Een juiste FQDN eindigt met een punt, wat de wortel van de DNS-hiërarchie aangeeft. Een voorbeeld van een FQDN is “mail.google.com.“. Soms vereist software die vraagt om FQDN het einde punt niet, maar het sluitende punt is vereist om te voldoen aan de ICANN-standaarden.
Naamserver
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
Naam servers kunnen “authoritative” zijn, wat betekent dat ze antwoorden geven op vragen over domeinen onder hun controle. Anders kunnen ze wijzen naar andere servers, of gecachte kopieën van gegevens van andere naam servers serveren.
Zonebestand
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
Zonebestanden bevinden zich in naam servers en definiëren over het algemeen de bronnen die beschikbaar zijn onder een specifiek domein, of de plaats waar men naartoe kan gaan om die informatie te verkrijgen.
Records
Binnen een zonebestand worden records bijgehouden. In zijn eenvoudigste vorm is een record in feite een enkele mapping tussen een bron en een naam. Deze kunnen een domeinnaam naar een IP-adres mappen, de naam servers voor het domein definiëren, de mail servers voor het domein definiëren, enz.
Hoe DNS Werkt
Nu je bekend bent met een aantal van de terminologie die wordt gebruikt bij DNS, hoe werkt het systeem eigenlijk?
Het systeem is heel eenvoudig op een hoog niveau, maar is zeer complex als je naar de details kijkt. Over het algemeen is het echter een zeer betrouwbare infrastructuur die essentieel is geweest voor de adoptie van het internet zoals we dat vandaag kennen.
Rootservers
Zoals we hierboven hebben gezegd, is DNS in essentie een hiërarchisch systeem. Boven aan dit systeem staan de zogenaamde “rootservers”. Deze servers worden beheerd door verschillende organisaties en krijgen autoriteit toegewezen door ICANN (Internet Corporation for Assigned Names and Numbers).
Er zijn momenteel 13 rootservers in bedrijf. Omdat er echter een ongelooflijk aantal namen moet worden opgelost per minuut, wordt elk van deze servers eigenlijk gespiegeld. Het interessante aan deze opstelling is dat elk van de spiegels voor een enkele rootservers hetzelfde IP-adres delen. Wanneer er verzoeken worden gedaan voor een bepaalde rootservers, wordt het verzoek doorgestuurd naar de dichtstbijzijnde spiegel van die rootservers.
Wat doen deze root servers? Root servers behandelen verzoeken om informatie over Top-level domeinen. Dus als er een verzoek binnenkomt voor iets dat een lagere-level naamserver niet kan oplossen, wordt er een query gemaakt naar de rootserver voor het domein.
De root servers zullen eigenlijk niet weten waar het domein wordt gehost. Ze zullen echter de aanvrager kunnen doorverwijzen naar de naamservers die het specifiek gevraagde top-level domein beheren.
Dus als er een verzoek voor “www.wikipedia.org” wordt gedaan aan de rootserver, zal de rootserver het resultaat niet in zijn records vinden. Het zal zijn zonebestanden controleren op een vermelding die overeenkomt met “www.wikipedia.org”. Het zal er geen vinden.
In plaats daarvan vindt het een record voor de “org” TLD en geeft het de aanvragende entiteit het adres van de naamserver die verantwoordelijk is voor “org” adressen.
TLD Servers
De aanvrager stuurt dan een nieuw verzoek naar het IP-adres (gegeven door de rootserver) dat verantwoordelijk is voor het top-level domein van het verzoek.
Dus, om ons voorbeeld voort te zetten, zou het een verzoek sturen naar de naamserver die verantwoordelijk is voor het kennen van “org” domeinen om te zien of het weet waar “www.wikipedia.org” is gelegen.
Opnieuw zal de aanvrager kijken naar “www.wikipedia.org” in zijn zonebestanden. Het zal dit record niet in zijn bestanden vinden.
Echter, het zal een record vinden met de IP-adresvermelding van de naamserver die verantwoordelijk is voor “wikipedia.org“. Dit komt veel dichter bij het antwoord dat we willen.
Domein-Level Naamservers
Op dit punt heeft de aanvrager het IP-adres van de naamserver die verantwoordelijk is voor het weten van het daadwerkelijke IP-adres van de bron. Het stuurt een nieuwe aanvraag naar de naamserver met de vraag of het opnieuw ” www.wikipedia.org ” kan oplossen.
De naamserver controleert zijn zonebestanden en ontdekt dat het een zonebestand heeft dat is gekoppeld aan ” wikipedia.org “. In dit bestand staat een record voor de host “www”. Dit record geeft het IP-adres aan waar deze host zich bevindt. De naamserver geeft het uiteindelijke antwoord terug aan de aanvrager.
Wat is een Oplossende Naamserver?
In het bovenstaande scenario verwezen we naar een “aanvrager”. Wat is de aanvrager in deze situatie?
In bijna alle gevallen zal de aanvrager wat wij een “oplossende nameserver” noemen, zijn. Een oplossende nameserver is geconfigureerd om vragen aan andere servers te stellen. Het is in feite een tussenpersoon voor een gebruiker die eerdere queryresultaten in cache opslaat om de snelheid te verbeteren en de adressen van de root-servers kent om verzoeken op te lossen voor dingen waar het nog niet van op de hoogte is.
Over het algemeen zal een gebruiker een paar oplossende nameservers geconfigureerd hebben op hun computersysteem. De oplossende nameservers worden meestal geleverd door een internetprovider (ISP) of andere organisaties. Bijvoorbeeld Google biedt oplossende DNS-servers die je kunt bevragen. Deze kunnen automatisch of handmatig op je computer geconfigureerd zijn.
Wanneer je een URL in de adresbalk van je browser typt, kijkt je computer eerst lokaal of het kan achterhalen waar de bron zich bevindt. Het controleert het “hosts” bestand op de computer en een paar andere locaties. Vervolgens stuurt het het verzoek naar de oplossende nameserver en wacht het op het ontvangen van het IP-adres van de bron.
De oplossende nameserver controleert dan zijn cache voor het antwoord. Als het dit niet vindt, doorloopt het de bovenstaande stappen.
Oplossende nameservers comprimeren in feite het aanvraagproces voor de eindgebruiker. De clients hoeven alleen maar te weten dat ze de oplossende nameservers moeten vragen waar een bron zich bevindt en erop vertrouwen dat ze het zullen onderzoeken en het definitieve antwoord zullen teruggeven.
Zone-bestanden
We hebben in het bovenstaande proces gesproken over het idee van “zone-bestanden” en “records”.
Zone-bestanden zijn de manier waarop nameservers informatie opslaan over de domeinen waar ze bekend mee zijn. Elk domein waar een nameserver van op de hoogte is, wordt opgeslagen in een zone-bestand. De meeste verzoeken die naar de gemiddelde nameserver komen, zijn niet iets waarvoor de server zone-bestanden zal hebben.
Als het geconfigureerd is om recursieve queries te verwerken, zoals een oplossende nameserver, zal het het antwoord vinden en teruggeven. Anders zal het de aanvragende partij vertellen waar ze vervolgens moeten zoeken.
Hoe meer zone-bestanden een nameserver heeft, hoe meer verzoeken het autoritatief kan beantwoorden.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
De zone’s $ORIGIN is standaard een parameter gelijk aan het hoogste niveau van autoriteit van de zone.
Dus als een zone-bestand wordt gebruikt om het domein “example.com.” te configureren, zou de $ORIGIN worden ingesteld op example.com..
Dit wordt ofwel geconfigureerd aan het begin van het zone-bestand of het kan worden gedefinieerd in het configuratiebestand van de DNS-server dat verwijst naar het zone-bestand. Hoe dan ook, deze parameter beschrijft waar de zone autoriteit over heeft.
Vergelijkbaar configureert de $TTL de “time to live” van de verstrekte informatie. Het is in feite een timer. Een cachelende nameserver kan eerder opgevraagde resultaten gebruiken om vragen te beantwoorden totdat de TTL-waarde is verstreken.
Recordtypes
Binnen het zonebestand kunnen we verschillende recordtypen hebben. We zullen hier enkele van de meer voorkomende (of verplichte typen) bespreken.
SOA-records
De Start of Authority, of SOA, record is een verplichte record in alle zonebestanden. Het moet de eerste echte record in een bestand zijn (hoewel $ORIGIN– of $TTL-specificaties hierboven kunnen verschijnen). Het is ook een van de moeilijkst te begrijpen.
De start van de autoriteitsrecord ziet er ongeveer zo uit:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Laten we uitleggen waar elk deel voor is:
-
domain.com.: Dit is de root van de zone. Dit geeft aan dat het zonebestand voor het domeindomain.com.is. Vaak zie je dit vervangen door@, wat slechts een aanduiding is die de inhoud van de$ORIGIN-variabele vervangt waar we hierboven over hebben geleerd. -
IN SOA: Het gedeelte “IN” betekent internet (en zal aanwezig zijn in veel records). De SOA is de indicator dat dit een Start of Authority-record is.
-
ns1.domain.com.: Dit definieert de primaire nameserver voor dit domein. Nameservers kunnen primair of secundair zijn, en als dynamische DNS is geconfigureerd, moet één server een “primaire” zijn, die hier wordt ingevoerd. Als je dynamische DNS niet hebt geconfigureerd, is dit gewoon een van je primaire nameservers. -
admin.domain.com.: Dit is het e-mailadres van de beheerder voor deze zone. Het “@”-teken wordt vervangen door een punt in het e-mailadres. Als het naamgedeelte van het e-mailadres normaal gesproken een punt bevat, wordt dit vervangen door een “” in dit deel ([email protected]wordtyour\name.domain.com). -
12083: Dit is het serienummer voor het zonebestand. Elke keer dat u een zonebestand bewerkt, moet u dit nummer verhogen voor het correct doorgeven van het zonebestand. Secundaire servers controleren of het serienummer van de primaire server voor een zone groter is dan degene die ze op hun systeem hebben. Als dat zo is, wordt het nieuwe zonebestand opgevraagd, zo niet, dan blijft het originele bestand in gebruik.
-
3h: Dit is het vernieuwingsinterval voor de zone. Dit is de tijd die de secundaire server wacht voordat deze de primaire server opnieuw raadpleegt voor wijzigingen in het zonebestand.
-
30m: Dit is het herhaalinterval voor deze zone. Als de secundaire server geen verbinding kan maken met de primaire wanneer de vernieuwingsperiode voorbij is, zal het deze hoeveelheid tijd wachten en opnieuw proberen de primaire te bevragen.
-
3w: Dit is de vervaltijd. Als een secundaire nameserver gedurende deze tijd geen contact heeft kunnen maken met de primaire, geeft het geen antwoorden meer terug als een gezaghebbende bron voor deze zone.
-
1h: Dit is de hoeveelheid tijd dat de nameserver een naamfout in de cache zal bewaren als het de gevraagde naam niet kan vinden in dit bestand.
A and AAAA Records
Beide van deze records koppelen een host aan een IP-adres. Het “A”-record wordt gebruikt om een host te koppelen aan een IPv4 IP-adres, terwijl “AAAA”-records worden gebruikt om een host te koppelen aan een IPv6-adres.
De algemene opmaak van deze records is als volgt:
host IN A IPv4_address
host IN AAAA IPv6_address
Dus aangezien ons SOA-record een primaire server noemde op “ns1.domain.com“, zouden we dit moeten koppelen aan een adres naar een IP-adres aangezien “ns1.domain.com” zich bevindt binnen de ” domain.com “zone die dit bestand definieert.
Het record zou er als volgt uit kunnen zien:
ns1 IN A 111.222.111.222
Merk op dat we niet de volledige naam hoeven te geven. We kunnen gewoon de host geven, zonder de FQDN en de DNS-server vult de rest in met de $ORIGIN-waarde. We kunnen echter net zo goed de volledige FQDN gebruiken als we semantisch willen zijn:
ns1.domain.com. IN A 111.222.111.222
In de meeste gevallen is dit waar je je webserver als “www” zult definiëren:
www IN A 222.222.222.222
We moeten ook aangeven waar het basisdomein naar verwijst. Dit kunnen we zo doen:
domain.com. IN A 222.222.222.222
We hadden ook het “@”-teken kunnen gebruiken om te verwijzen naar het basisdomein:
@ IN A 222.222.222.222
We hebben ook de mogelijkheid om alles wat onder dit domein valt en niet expliciet is gedefinieerd naar deze server te laten verwijzen. Dit kunnen we doen met het ” * ” jokerteken:
* IN A 222.222.222.222
Al deze methoden werken net zo goed met AAAA-records voor IPv6-adressen.
CNAME-records
CNAME-records definiëren een alias voor de canonieke naam van uw server (gedefinieerd door een A- of AAAA-record).
Bijvoorbeeld, we kunnen een A-naamrecord hebben dat de host “server1” definieert en vervolgens “www” als een alias voor deze host gebruiken:
server1 IN A 111.111.111.111
www IN CNAME server1
Wees ervan bewust dat deze aliassen gepaard gaan met enige prestatieverlies omdat ze een extra query aan de server vereisen. Meestal kan hetzelfde resultaat bereikt worden door het gebruik van extra A of AAAA records.
Een geval waarin een CNAME aanbevolen wordt, is om een alias te bieden voor een bron buiten de huidige zone.
MX Records
MX records worden gebruikt om de mailuitwisselingen te definiëren die voor het domein gebruikt worden. Dit helpt e-mailberichten correct bij je mailserver aan te komen.
In tegenstelling tot veel andere recordtypen, mappen mailrecords over het algemeen geen host naar iets, omdat ze op de hele zone van toepassing zijn. Daarom zien ze er meestal zo uit:
IN MX 10 mail.domain.com.
Let op dat er geen hostnaam aan het begin staat.
Let ook op dat er een extra nummer in staat. Dit is het voorkeursnummer dat computers helpt beslissen naar welke server ze mail moeten sturen als er meerdere mailservers gedefinieerd zijn. Lagere nummers hebben een hogere prioriteit.
Het MX record zou over het algemeen moeten wijzen naar een host gedefinieerd door een A of AAAA record, en niet één gedefinieerd door een CNAME.
Stel, we hebben twee mailservers. Dan zouden er records moeten zijn die er ongeveer zo uitzien:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
In dit voorbeeld is de host “mail1” de voorkeurse-mailuitwisselingsserver.
We zouden dat ook zo kunnen schrijven:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NS Records
Dit recordtype definieert de nameservers die worden gebruikt voor deze zone.
Je vraagt je misschien af: “als het zonebestand zich op de nameserver bevindt, waarom moet het dan naar zichzelf verwijzen?”. Een deel van wat DNS zo succesvol maakt, is zijn meerdere niveaus van caching. Een reden om nameservers binnen het zonebestand te definiëren, is dat het zonebestand eigenlijk wordt geserveerd vanuit een gecachte kopie op een andere nameserver. Er zijn andere redenen waarom de nameservers gedefinieerd moeten worden op de nameserver zelf, maar daar zullen we hier niet verder op ingaan.
Net als de MX-records zijn dit zonebrede parameters, dus ze hebben ook geen hosts nodig. Over het algemeen zien ze er zo uit:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Je moet minstens twee nameservers gedefinieerd hebben in elk zonebestand om correct te werken als er een probleem is met één server. De meeste DNS-serversoftware beschouwt een zonebestand als ongeldig als er slechts één nameserver is.
Zoals altijd, neem de mapping voor de hosts op met A- of AAAA-records:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
Er zijn nogal wat andere recordtypes die je kunt gebruiken, maar dit zijn waarschijnlijk de meest voorkomende types die je tegen zult komen.
PTR Records
De PTR-records worden gebruikt om een naam te definiëren die is gekoppeld aan een IP-adres. PTR-records zijn het omgekeerde van een A- of AAAA-record. PTR-records zijn uniek omdat ze beginnen bij de .arpa-root en worden gedelegeerd aan de eigenaars van de IP-adressen. De Regionale Internetregistries (RIR’s) beheren de IP-adresdelegatie aan organisaties en dienstverleners. De Regionale Internetregistries omvatten APNIC, ARIN, RIPE NCC, LACNIC en AFRINIC.
Hier is een voorbeeld van hoe een PTR-record voor 111.222.333.444 eruit zou zien:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Dit voorbeeld van een PTR-record voor een IPv6-adres toont het nibble-formaat van het omgekeerde van de IPv6 DNS-server van Google 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
De opdrachtregeltool dig met de -x-vlag kan worden gebruikt om de omgekeerde DNS-naam van een IP-adres op te zoeken.
Hier is een voorbeeld van een dig-opdracht. De +short wordt toegevoegd om de uitvoer te beperken tot de omgekeerde DNS-naam.
De uitvoer voor de bovenstaande dig-opdracht zal de domeinnaam zijn in het PTR-record voor het IP-adres:
google-public-dns-b.google.com.
Servers op het internet gebruiken PTR-records om domeinnamen binnen logboekvermeldingen te plaatsen, geïnformeerde spamverwerkingsbeslissingen te nemen en gemakkelijk leesbare details over andere apparaten weer te geven.
De meest gebruikte e-mailservers zullen de PTR-record van een IP-adres opzoeken waarvan het e-mails ontvangt. Als het bron-IP-adres geen bijbehorende PTR-record heeft, kunnen de verzonden e-mails worden behandeld als spam en afgewezen. Het is niet belangrijk dat de FQDN in de PTR overeenkomt met de domeinnaam van de verzonden e-mail. Wat belangrijk is, is dat er een geldige PTR-record is met een overeenkomstige en overeenkomende voorwaartse A-record.
Normaal gesproken krijgen netwerkrouters op het internet PTR-records die overeenkomen met hun fysieke locatie. Bijvoorbeeld, je kunt verwijzingen zien naar ‘NYC’ of ‘CHI’ voor een router in New York City of Chicago. Dit is handig bij het uitvoeren van een traceroute of MTR en het bekijken van de route die internetverkeer aflegt.
De meeste providers die dedicated servers of VPS-services aanbieden, zullen klanten de mogelijkheid geven om een PTR-record in te stellen voor hun IP-adres. DigitalOcean zal automatisch het PTR-record van een Droplet toewijzen wanneer de Droplet is vernoemd naar een domeinnaam. De naam van de Droplet wordt toegewezen tijdens de creatie en kan later worden bewerkt via de instellingenpagina van het Droplet-besturingspaneel.
Let op: Het is belangrijk dat de FQDN in het PTR-record een overeenkomstig en overeenkomend voorwaarts A-record heeft. Voorbeeld: 111.222.333.444 heeft een PTR van server.example.com en server.example.com is een A-record dat verwijst naar 111.222.333.444.
CAA-records
CAA-records worden gebruikt om te specificeren welke Certificate Authorities (CAs) zijn toegestaan om SSL/TLS-certificaten uit te geven voor jouw domein. Vanaf 8 september 2017 zijn alle CAs verplicht om deze records te controleren voordat ze een certificaat uitgeven. Als er geen record aanwezig is, mag elke CA een certificaat uitgeven. Anders mogen alleen de gespecificeerde CAs certificaten uitgeven. CAA-records kunnen worden toegepast op afzonderlijke hosts of op hele domeinen.
Een voorbeeld van een CAA-record volgt:
example.com. IN CAA 0 issue "letsencrypt.org"
De host, IN, en recordtype (CAA) zijn veelvoorkomende DNS-velden. De CAA-specifieke informatie hierboven is het gedeelte 0 issue "letsencrypt.org". Het bestaat uit drie delen: vlaggen (0), tags (issue) en waarden ("letsencrypt.org").
- Vlaggen zijn een geheel getal dat aangeeft hoe een CA tags moet behandelen die het niet begrijpt. Als de vlag
0is, wordt het record genegeerd. Als1, moet de CA weigeren het certificaat uit te geven. - Tags zijn strings die het doel van een CAA-record aanduiden. Momenteel kunnen ze
issuezijn om een CA te autoriseren certificaten aan te maken voor een specifieke hostnaam,issuewildom wildcard-certificaten goed te keuren, ofiodefom een URL te definiëren waar CAs beleidsovertredingen kunnen rapporteren. - Waarden zijn een tekenreeks die is gekoppeld aan het label van het record. Voor
issueenissuewildzal dit meestal het domein zijn van de CA waarvoor je toestemming verleent. Vooriodefkan dit de URL zijn van een contactformulier, of eenmailto:-link voor e-mailfeedback.
Je kunt dig gebruiken om CAA-records op te halen met de volgende opties:
Voor meer gedetailleerde informatie over CAA-records, kun je RFC 6844 lezen, of onze tutorial Hoe CAA-records maken en beheren met DigitalOcean DNS
Conclusie
Je zou nu een vrij goed begrip moeten hebben van hoe DNS werkt. Hoewel het algemene idee relatief eenvoudig te begrijpen is zodra je bekend bent met de strategie, kan dit nog steeds moeilijk zijn voor onervaren beheerders om in de praktijk te brengen.
Voor een overzicht, bekijk Hoe je domeinen instelt binnen het DigitalOcean Control Panel.