Overzicht van DNS-terminologieën, componenten en concepten

DNS (Domain Name System) is een van de cruciale componenten die het internet aandrijven. Een goed begrip van hoe DNS werkt kan helpen bij het diagnosticeren van problemen met websiteconfiguratie en je begrip verbreden van wat er achter de schermen gebeurt.

In deze gids bespreken we enkele fundamentele concepten van DNS om je een solide basis te bieden bij het werken met je DNS-configuratie. Deze gids helpt ook bij het instellen van je eigen domeinnaam of DNS-server.

Laten we beginnen!

Domeinterminologie

Eerst moeten we een begrip opbouwen van de termen die we gaan gebruiken. Misschien ben je al bekend met sommige daarvan uit andere contexten. Er zijn echter veel specifieke termen wanneer we het hebben over domeinnamen en DNS die in andere gebieden van de informatica niet veel worden besproken.

• Domain Name System

Het domeinnaamsysteem (kortweg DNS) is een netwerksysteem dat gebruiksvriendelijke domeinnamen vertaalt naar unieke IP-adressen.

• Domeinnaam

Een domeinnaam verwijst naar de gebruiksvriendelijke naam die wordt gebruikt om te koppelen aan een internetbron. Bijvoorbeeld, “cloudsigma.com” is een domeinnaam. Sommigen zullen beweren dat alleen het “cloudsigma”-deel de domeinnaam is, maar over het algemeen verwijst het naar het geheel.

De URL “cloudsigma.com” is gekoppeld aan de servers die eigendom zijn van CloudSigma. Wanneer je de URL in de webbrowser invoert, communiceert deze met de DNS om verbinding te maken met het IP-adres van de doelserver.

• IP-adres

Een IP-adres fungeert als een netwerkadres voor een apparaat dat is aangesloten op het netwerk. Elk IP-adres moet uniek zijn binnen het netwerk. In de context van websites is het netwerk meestal het hele internet.

Er zijn twee soorten IP-adressen:

• • IPv4: Dit is de meest voorkomende vorm van een IP-adres. Het wordt geschreven als een set van vier getallen, waarbij elke set maximaal 3 cijfers heeft. Elke set is gescheiden door een punt. Het bereik van IPv4 is van 0.0.0.0 tot 255.255.255.255.

  • IPv6: Het is een modernere standaard die is ontwikkeld om het probleem op te lossen van uitputting van IPv4-adressen. IPv4 ondersteunt tot 232 unieke adressen, terwijl IPv6 ondersteunt tot 2128 adressen. Elk IPv6-adres is geschreven in hexadecimale cijfers. Het kan maximaal 32 cijfers bevatten, verdeeld over 8 secties (4 cijfers per sectie). Elke sectie is gescheiden door een dubbele punt (:).

Top-level domein

Een top-level domein (kortweg TLD) is het meest algemene deel van het domein. Het verwijst naar het uiterste deel aan de rechterkant (gescheiden door een punt). Enkele van de meest voorkomende top-level domeinen zijn:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

Wat betreft domeinnamen staan deze domeinen bovenaan de hiërarchie. ICANN (Internet Corporation for Assigned Names and Numbers) kan een vergunning verlenen voor de controle van bepaalde partijen over top-level domeinen. Met toestemming kunnen deze partijen domeinnamen onder de TLD distribueren (meestal via een domeinregistrar).

• Hosts

Binnen het domein kan de eigenaar individuele hosts specificeren, die verwijzen naar afzonderlijke machines/diensten die toegankelijk zijn via een domein. Het is bijvoorbeeld een gangbare praktijk om de webservers toegankelijk te maken via het kale domein ( example.com) en de “host”-definitie “www  ( www.example.com).

Het is mogelijk om extra hosts onder het algemene domein te hebben, bijvoorbeeld API-toegang via de “api”-host ( api.example.com), FTP-toegang via de “ftp”- of “files”-host ( ftp.example.com of files.example.com).

Let op dat de domeinnamen willekeurig mogen zijn, zolang ze maar uniek zijn binnen het domein.

• Subdomein

Een subdomein is een onderwerp dat gerelateerd is aan hosts. DNS functioneert in een hiërarchie. Een TLD kan vele domeinen onder zich hebben. Bijvoorbeeld, “ example.com”, “ cloudsigma.com”, enz. vallen allemaal onder de “com”-TLD. In dat opzicht is een subdomein een verwijzing naar elk domein dat deel uitmaakt van het doeldomein. We kunnen dus zeggen dat “example.com” een subdomein is van “com”. Over het algemeen wordt het “example”-gedeelte aangeduid als een SLD (second-level domain).

Op vergelijkbare wijze kan een domein alle “subdomeinen” beheren die eronder vallen. Dit is meestal waar naar verwezen wordt met “subdomein”. Bijvoorbeeld, “ history.example.com” is een subdomein van “ example.com”.

Het belangrijkste verschil tussen een hostnaam en een subdomein is dat een host een computer/bron definieert, terwijl een subdomein het hoofddomein uitbreidt. Wanneer we het over subdomeinen of hosts hebben, kun je dit controleren door naar het meest linkse deel van een domein te kijken, aangezien dat het meest specifiek is. Dat is hoe DNS werkt: van het meest specifieke (uiterst links) naar het minst specifieke (uiterst rechts).

• Volledig gekwalificeerde domeinnaam

Een volledig gekwalificeerde domeinnaam (kortweg FQDN) verwijst naar een absolute domeinnaam. In het DNS-systeem kunnen domeinen ten opzichte van elkaar worden opgegeven. Dit kan leiden tot enige ambiguïteit. Een FQDN is echter een absolute naam die verwijst naar de absolute root van het domeinnaamsysteem.

Dit betekent dat de FQDN elk hoofddomein specificeert, inclusief de TLD. Een goed voorbeeld zou zijn “ mail.google.com”. In specifieke gevallen eindigt de FQDN mogelijk niet met een punt, maar deze moet een afsluitende punt hebben (vereist door de ICANN-standaarden).

• Nameserver

Een nameserver is een computer die speciaal is ingericht voor het vertalen van domeinnamen naar IP-adressen. Nameservers dragen het grootste deel van de belasting in het DNS-systeem. Omdat het totale aantal verzoeken om domeinvertalingen te hoog is voor één enkele server, worden de verzoeken vaak omgeleid naar andere nameservers om de druk te verlichten.

Een nameserver kan “authoritatief” zijn, wat betekent dat deze alleen antwoorden geeft op query's over domeinen die onder zijn beheer vallen. Dergelijke servers kunnen het verzoek doorsturen naar andere nameservers of een gecachte kopie van de gegevens van andere nameservers leveren.

• Zonebestand

Een zonebestand is een tekstbestand dat de koppelingen tussen domeinnamen en IP-adressen bevat. Het dient als de database van het DNS-systeem. Dit is de catalogus die DNS gebruikt om te bepalen met welk IP-adres contact moet worden opgenomen bij het afhandelen van een gebruikersverzoek voor een bepaalde domeinnaam.

Over het algemeen hosten de nameservers de zonebestanden en definiëren ze de bronnen die beschikbaar zijn onder een enkel domein. Het kan ook informatie bevatten over waar men heen moet om die informatie te verkrijgen.

• Records

Een zonebestand bestaat uit talloze records. Hier wordt een record gedefinieerd als een enkele koppeling tussen een bron en een naam. Records kunnen een koppeling zijn van een domeinnaam naar een IP-adres, bronnen die beschikbaar zijn onder een specifiek domein, of verwijzingen naar locaties om de informatie te verkrijgen.

DNS in actie

Tot nu toe hebben we kennisgemaakt met enkele veelvoorkomende termen die te maken hebben met DNS. Maar hoe werkt het systeem eigenlijk? Op hoofdlijnen lijkt het systeem misschien heel eenvoudig. Als we echter dieper op de details ingaan, wordt de werkelijke complexiteit ervan duidelijk. Over het geheel genomen is het DNS-systeem belangrijk voor de brede acceptatie van het internet.

• Rootservers

DNS functioneert in de kern in een hiërarchie. Aan de top van het systeem bevinden zich de “rootservers”. Deze servers staan onder controle van verschillende organisaties. De autoriteit van deze servers is gedelegeerd door ICANN (Internet Corporation for Assigned Names and Numbers).

Momenteel zijn er ongeveer 13 rootservers in bedrijf. Vanwege de belasting is elk van deze servers echter gespiegeld. Het is belangrijk om te weten dat alle spiegelservers hetzelfde IP-adres delen als de rootserver. Wanneer er een verzoek wordt gedaan aan de rootserver, wordt het verzoek omgeleid naar de dichtstbijzijnde spiegelserver van die server.

Wat zijn de taken van de rootservers? Ze leveren informatie over top-level domeinen. Wanneer een nameserver op een lager niveau een verzoek niet kan omzetten, wordt dit omgeleid naar de rootserver van het domein.

De rootserver weet echter niet echt wat de locatie van het domein is. Deze stuurt het verzoek alleen door naar de server die het specifiek aangevraagde top-level domein afhandelt. Als er bijvoorbeeld een verzoek wordt gedaan voor “ blog.cloudsigma.com”, zal de rootserver dit niet in zijn records hebben. Hij zal zijn zonebestanden doorzoeken, maar er zal geen record voor zijn. In plaats daarvan zal hij de “com”-TLD herkennen en de verzoekende entiteit doorverwijzen naar de nameserver die “com”-adressen afhandelt.

• TLD-servers

Voortbordurend op ons vorige voorbeeld, zal de verzoekende entiteit het verzoek nu naar het IP-adres sturen (verstrekt door de rootserver). In het geval van “ blog.cloudsigma.com”, zal de “com”-nameserver zijn records in zijn zonebestanden doorzoeken.

Er zal geen record zijn dat overeenkomt met het verzoek. Wel zal hij een record vinden met het IP-adres van de nameserver die verantwoordelijk is voor “ cloudsigma.com”.

• Nameserver op domeinniveau

Nu heeft de verzoekende entiteit het IP-adres van de nameserver die daadwerkelijk de informatie host over “ blog.cloudsigma.com”. Deze zal nu een nieuw verzoek naar de server sturen met de vraag om “www.cloudsigma.com” op te lossen.

Net als voorheen zal de nameserver zijn zonebestanden controleren en degene vinden die gekoppeld is aan “ cloudsigma.com”. In dit bestand bevindt zich een vermelding voor de “www”-host. Dit record beschrijft waar de host zich bevindt. Het uiteindelijke antwoord wordt vervolgens doorgegeven aan de verzoekende entiteit.

• Resolving nameserver

In het voorbeeld noemden we een verzoekende entiteit. Wat is dat? In de meeste gevallen is de aanvrager een “resolving nameserver”. Dit is een server die is geconfigureerd om vragen te stellen aan andere servers. Hij fungeert als een tussenliggende server voor gebruikers. Hij slaat de resultaten op in de cache om de snelheid te verbeteren.

Elke gebruiker heeft meestal een paar resolving nameservers geconfigureerd op zijn systeem. Over het algemeen worden de resolving nameservers aangeboden door de ISP of andere organisaties. Bijvoorbeeld, Google biedt openbare resolving DNS-servers om query's naar te sturen. U kunt dit handmatig configureren op uw systeem.

Wanneer u een URL invoert in de webbrowser, zoekt deze naar de locatie van de bron. Eerst wordt de zoekopdracht lokaal uitgevoerd. Dit omvat het “hosts”-bestand (en enkele andere locaties). Indien niet gevonden, wordt het verzoek naar de resolving nameserver gestuurd. Na ontvangst van het verzoek zoekt de resolving nameserver in zijn cache naar het antwoord. Indien niet gevonden, doorloopt hij de eerder genoemde stappen.

Resolving nameservers vereenvoudigen het aanvraagproces voor de eindgebruiker. De client hoeft de resolving nameservers alleen maar te vragen naar de locatie van een bron. De nameserver zal dit onderzoeken en het uiteindelijke antwoord terugsturen.

• Zonebestanden

We hebben de concepten van “zonebestanden” en “records” al besproken. Maar hoe werken ze?

Zonebestanden fungeren als de database voor de nameservers en slaan de informatie op over de domeinen die ze kennen. Alle domeinen die een nameserver kent, worden opgeslagen in het bijbehorende zonebestand. De meeste verzoeken die bij een nameserver binnenkomen, worden echter niet door het zonebestand opgelost. Als de serverconfiguratie is ingesteld om recursieve query's af te handelen (bijvoorbeeld resolving nameservers), zal deze het antwoord retourneren. Anders zal deze de verzoekende partij doorverwijzen naar een andere plek om verder te zoeken.

Hoe meer zonebestanden een nameserver host, hoe autoritatiever de antwoorden zullen zijn. Zonebestanden beschrijven een DNS-“zone” (een subset van het gehele DNS-naamgevingssysteem). Over het algemeen bevat een zonebestand de configuratiegegevens van slechts één enkel domein. Het kan talloze records bevatten die de locatie van de bronnen van het betreffende domein definiëren.

De $ORIGIN-parameter van een zone is gelijk aan het hoogste autoriteitsniveau van de zone. Een zonebestand voor “ cloudsigma.com” zal zijn $ORIGIN hebben als “ cloudsigma.com”. De waarde van de parameter kan aan het begin van het zonebestand of in de configuratie van de DNS-server worden opgeslagen. Hoe dan ook, de parameter beschrijft voor welke zone het bestand gezaghebbend is.

De $TTL parameter stelt de “time to live”-informatie in van het resultaat dat het levert. Het kan worden omschreven als een timer die een caching-server kan gebruiken om de geldigheid van de gecachte antwoorden bij te houden. Als de TTL-waarde verloopt, is het antwoord niet langer geldig en wordt het weggegooid.

• Recordtypen

De zonebestanden bestaan uit talrijke records. Er zijn verschillende soorten records. Hierna zullen we enkele van de meest voorkomende (en verplichte) typen records bespreken:

SOA-records

Het Start of Authority-record (kortweg SOA) is verplicht in alle zonebestanden. Het moet het eerste echte record in het bestand zijn. Vermeldingen zoals $ORIGIN of $TTL mogen vooraf verschijnen.

Het SOA-record is een van de complexere typen records. De structuur ervan ziet er ongeveer zo uit:

Laten we het ontleden:

• • example.com: Dit gedeelte definieert de root van de zone. In dit voorbeeld is het zonebestand voor het domein “ example.com”. Soms kan de waarde worden vervangen door @ (een tijdelijke aanduiding om de waarde te vervangen van $ORIGIN).

  • IN SOA: De term “IN” betekent “internet”. Je vindt deze in veel records. De term “SOA” geeft aan dat het een SOA-record is.

  • ns1.example.com: Deze waarde bevat de primaire nameserver voor het domein “ example.com”. Nameservers kunnen primair of secundair zijn. Als deze is geconfigureerd met dynamische DNS, moet er één “primaire” server zijn. Als er geen dynamische DNS is geconfigureerd, is dit een van de primaire nameservers.

  • admin.example.com: Hier komt het e-mailadres van de beheerder van de zone. Let op dat de @ hier is vervangen door . hier. Als het oorspronkelijke e-mailadres een punt bevat, wordt deze vervangen door een \. Bijvoorbeeld, “ my.domain@example.com” zou “ wordenmy\domain.example.com”.

  • 12083: Dit is het serienummer van het zonebestand. Elke keer dat het zonebestand wordt bewerkt, moet het nummer worden bijgewerkt om het bestand correct te laten verspreiden. Secundaire servers gebruiken dit serienummer om bij te houden of hun eigen zonebestanden up-to-date zijn.

  • 3h: Dit vertegenwoordigt het verversingsinterval voor de zone. Secundaire servers wachten deze hoeveelheid tijd voordat ze controleren op updates van het zonebestand.

  • 30m: Deze waarde vertegenwoordigt het pogingsinterval van de zone. Als een secundaire server er niet in slaagt verbinding te maken met de primaire server zodra de verversingstijd om is, wacht deze deze hoeveelheid tijd voordat de primaire server opnieuw wordt gepolld.

  • 3w: Deze waarde vertegenwoordigt de vervaltijd. Als een secundaire server gedurende deze hoeveelheid tijd geen verbinding kan maken met de primaire server, stopt deze met het retourneren van antwoorden als “gezaghebbend”.

  • 1h: Deze waarde vertegenwoordigt de hoeveelheid tijd dat de nameserver een naamfout cachet als deze niet in het zonebestand is gevonden.

A- en AAAA-records

Deze records leggen een koppeling vast tussen een host en een IP-adres. Hierbij geeft het “A”-record de IPv4-koppeling naar de host aan en AAAA de IPv6-koppeling.

Dit is de basisstructuur van de A- en AAAA-records:

In het voorbeeld van het SOA-record noemden we de nameserver “ ns1.exampel.com”. De nameserver valt onder het domein “ example.com”. Dit is hoe het A-record ervan eruit zou zien:

Merk op dat we niet de volledige naam hoefden op te geven. Met alleen de hostnaam (zonder de FQDN) kan de DNS-server de rest invullen met de waarde van $ORIGIN. We kunnen echter nog steeds de FQDN gebruiken:

Hier is hoe u de webserver definieert als “www”:

We moeten ook de koppeling naar het basisdomein opnemen. De invoer zou er als volgt uitzien:

Als alternatief kunnen we het @ symbool gebruiken om het basisdomein aan te duiden (in plaats van de volledige naam):

Het is een goede gewoonte om een wildcard-invoer op te nemen die de optie biedt om alles onder dit domein op te lossen dat niet expliciet is gedefinieerd:

Dezelde structuur is van toepassing op AAAA-records. Het enige verschil zijn de IPv6-adressen.

CNAME-records

CNAME-records fungeren als een alias voor de canonieke naam van de server (gedefinieerd door een A- of AAAA-record). Bekijk het volgende voorbeeld:

Hier hebben we “server1” gebruikt als alias voor het definiëren van de naam “www”. Houd er rekening mee dat dergelijke snelkoppelingen prestatiekosten met zich meebrengen, omdat de server extra query's moet uitvoeren om het definitieve antwoord te krijgen. Afhankelijk van het aantal aliaslagen kan dit gemakkelijk leiden tot aanzienlijke prestatiekosten. Er is echter één specifiek geval dat profiteert van CNAME-aliasing, bijvoorbeeld het aanbieden van een bron buiten de huidige zone.

MX-records

MX-records definiëren de mailservers (mail exchanges) voor het domein. Het helpt de e-mail correct op de server aan te komen. In tegenstelling tot andere records koppelen MX-records een host niet aan iets, omdat ze van toepassing zijn op de hele zone. Dit is de reden waarom MX-records er ongeveer zo uitzien:

Merk op dat er geen hostnaam aan het begin van de invoer staat. U zult ook merken dat er een extra waarde in de regel staat. Dit is het voorkeursnummer dat helpt bepalen naar welke server de e-mail moet worden verzonden (als er meerdere mailservers zijn gedefinieerd). Hoe lager het nummer, hoe hoger de prioriteit.

Een MX-record moet verwijzen naar een host die is gedefinieerd door een A- of AAAA-record (niet door een CNAME). Met dat in gedachten, als er twee mailservers zijn geconfigureerd, zouden de records er als volgt uitzien:

In dit voorbeeld is, te oordelen naar het voorkeursnummer, “mail1” de voorkeursserver boven “mail2”. We kunnen de code verder verkorten door de volledige domeinnaam weg te laten:

NS-records

Deze records definiëren de naamservers voor de specifieke zone. Nu is de voor de hand liggende vraag: als het zonebestand zich binnen de naamserver bevindt, waarom is er dan een verwijzing naar zichzelf nodig? Een antwoord op die vraag zijn de meervoudige cachingmechanismen van het DNS-systeem. Het zonebestand kan in feite een gecachte kopie op andere servers zijn.

Net als de MX-records zijn de NS-records van toepassing op de hele zone. Ze hebben dus standaard geen specifieke host. NS-recordvermeldingen zien er ongeveer zo uit:

Het wordt aanbevolen om twee naamservers te definiëren voor het geval één server niet correct functioneert. Bovendien zullen de meeste DNS-servers een zonebestand weigeren als het slechts één enkele naamserver bevat.

U moet ook de koppeling van de hosts met A- of AAAA-records opnemen:

PTR-records

PTR-records zijn het omgekeerde van een klassiek A- of AAAA-record. Deze records worden gebruikt om een naam te definiëren die gekoppeld is aan een IP-adres. Deze records hebben een unieke eigenschap omdat ze beginnen bij de .arpa root en vertegenwoordigen de eigenaar van het IP-adres. Het zijn RIR’s (Regional Internet Registries) die IP-adressen distribueren naar organisaties en serviceproviders. De RIR's omvatten APNIC, AFRINIC, LACNIC, RIPE NCC en ARIN.

Bijvoorbeeld, een PTR-record voor 111.222.333.444 zou er ongeveer zo uitzien:

Bekijk in het volgende PTR-recordvoorbeeld de IPv6 DNS-server van Google’s 2001:4860:4860::8888:

We kunnen de dig-tool gebruiken met de vlag -x om de reverse DNS-naam van een IP-adres op te zoeken. Bekijk bijvoorbeeld het reverse DNS IP-adres van 8.8.4.4:

Internet servers gebruiken PTR-records om domeinnamen in logbestanden bij te houden, geïnformeerde beslissingen te nemen over de verwerking van spam en eenvoudig te lezen informatie over andere apparaten weer te geven.

Veelgebruikte e-mailservers zoeken het PTR-record op van het IP-adres vanwaar de e-mail is verzonden. Als het PTR-record leeg is, is de kans groot dat de e-mail spam is (en dus wordt geweigerd). Let op dat een overeenkomst tussen de FQDN en de domeinnaam van het PTR-record niet het belangrijkste is. De cruciale factor is of er een geldig PTR-record is gekoppeld aan een overeenkomend en bijbehorend forward A-record.

Over het algemeen hebben netwerkrouters op internet PTR-records die overeenkomen met hun fysieke locatie. Bijvoorbeeld, “NYC” of “CHI” zijn geldige verwijzingen voor routers in New York en Chicago. Deze techniek is nuttig bij het uitvoeren van een traceroute of MTR en het controleren van het pad dat de pakketten afleggen.

CAA-records

Deze records specificeren de CA's (Certificate Authorities) die SSL/TLS-certificaten voor uw domein mogen uitgeven. Sinds 8 september 2017 zijn alle CA's verplicht om de CAA-records te controleren voordat ze een certificaat uitgeven. Als er geen CAA-record bestaat, mag elke CA een certificaat uitgeven. Anders mogen alleen specifieke CA's certificaten uitgeven. CAA-records kunnen worden toegepast op afzonderlijke hosts of op een heel domein.

Hier is een voorbeeld van een CAA-record:

Het CAA-specifieke deel van de invoer is 0 issue "letsencrypt.org". Dit deel bestaat uit drie onderdelen:

• Vlaggen: Het is een geheel getal (integer) dat aangeeft hoe een CA moet omgaan met tags die deze niet begrijpt. Als de vlagwaarde is ingesteld op 0, dan wordt het record genegeerd. Als de waarde 1 is, dan moet de CA weigeren het certificaat uit te geven.
• Tags: Dit zijn tekenreeksen (strings) die het doel van een CAA-record aangeven. Momenteel zijn de geldige waarden onder andere issue (waarmee een CA wordt gemachtigd om certificaten uit te geven voor een specifiek domein), issuewild (waarmee wildcard-certificaten worden gemachtigd), en iodef (waarmee een URL wordt gedefinieerd waar CA's beleidsschendingen rapporteren).
• Waarden: Dit zijn tekenreeksen die gekoppeld zijn aan de tag van het record. Als de tag issue of issuewild is, is de waarde meestal het domein van de CA waaraan u toestemming verleent. Als de tag iodef is, is dit een URL van een contactformulier of een mailto: link voor e-mailfeedback.

We kunnen de dig-tool gebruiken om de CAA-records op te halen:

Voor meer diepgaande informatie over CAA-records, bekijk RFC 6844.

Laatste overwegingen

Deze gids beschrijft verschillende DNS-gerelateerde terminologieën. Het beschrijft ook hoe alle componenten samenhangen. Met dit grondige overzicht in gedachten, zou u een goed begrip moeten hebben van de werking van het DNS-systeem. Hoewel het algemene idee eenvoudig en gemakkelijk te begrijpen is, worden de finesses al snel complex. Voor onervaren beheerders kan het moeilijk zijn om deze concepten en strategieën toe te passen.

Bent u een CloudSigma-klant? Bekijk dan het beheren en bijwerken van reverse DNS/PTR-records voor uw CloudSigma-infrastructuur.

Veel computerplezier!