|
|
| Regel 1: |
Regel 1: |
| Het '''Domain Name System (DNS)''' is het systeem en protocol dat op het [[Internet]] voornamelijk gebruikt wordt om [[domeinnaam|domeinnamen]] naar [[IP-adres]]sen te vertalen en omgekeerd.
| | #Redirect[[dns]] |
| | |
| Een DNS-server of Domain Name Server is op deze technologie gebaseerd, en maakt deze vertalingen, zodat computers niet alleen via het (onpraktische) [[Internetprotocol|IP-adres]] benaderd kunnen worden, maar ook via een ''[[host]]name'' (computernaam). Ook het omgekeerde is mogelijk (reverse DNS): een IP-adres wordt vertaald naar de ingestelde hostname. Hoewel dit de meest gebruikte mogelijkheden zijn, wordt DNS ook op andere manieren gebruikt, bijvoorbeeld voor het bepalen van de [[Mailserver|mailservers]] voor een domein. Daarnaast kan ook het Sender Policy Framework (SPF) aan TXT records in een DNS-server worden toegevoegd. Mailservers kunnen aan de hand van dit record checken of de herkomst van de e-mail klopt. [[Sender Policy Framework|SPF]] is één van de instrumenten die zijn ingezet ter bestrijding van wereldwijde [[Spam (post)|spam]].
| |
| | |
| === Geschiedenis ===
| |
| Het leggen van een verbinding tussen IP-adres en naam werd oorspronkelijk gedaan met een [[Bestand (computer)|bestand]]. Naarmate [[Computernetwerk|netwerken]] groeiden was dit niet meer praktisch en kwam men uiteindelijk tot DNS.
| |
| Dit bestand is nog wel terug te zien onder veel besturingssystemen als <tt>hosts(.txt)</tt>. Soms wordt dit laatste bestand nog gebruikt om -bijvoorbeeld- lokale computers een makkelijke naam te geven of om tijdelijk voor een specifieke host het DNS systeem te negeren - soms handig bij het testen van een nieuwe [[website]] die nu nog een andere [[Uniform Resource Locator|URL]] heeft of lokaal draait. In tegenstelling tot het hosts bestand, is het DNS systeem bij uitstek een hiërarchische, gedistribueerde en redundante database, die goed onderhoudbaar is en bestand tegen groei.
| |
| | |
| === Basistechniek ===
| |
| DNS in praktische implementaties bestaat uit drie onderdelen:
| |
| * De ''stub resolver''
| |
| * De ''caching/recursing resolver'' (ook wel ''recursor'' genoemd)
| |
| * De ''authoritative nameserver''
| |
| | |
| Het opzoeken van data met behulp van DNS wordt in de regel een ''lookup'' genoemd. Software, zoals een [[webbrowser]], die een lookup wil doen vraagt dit aan de ''stub resolver''. Dit is relatief simpele software die, afhankelijk van de configuratie, de vraag kan stellen aan een ''recursor'' of eerst kan kijken in een bestand (zoals het onder o.a. [[Unix|Unix-afgeleiden]] bekende <tt>/etc/hosts</tt>).
| |
| | |
| De ''stub resolver'' stelt een DNS-pakket samen en stuurt dit naar de ''recursor''. Vaak levert de [[internetprovider]] een recursor en wordt deze gebruikt, alhoewel bij netwerken ook regelmatig een interne recursor wordt opgezet. De recursor is geavanceerder dan de stub resolver en zal in eerste instantie beginnen met het stellen van de [[Vraag (taal)|vraag]] aan een [[DNS-rootserver]]. Deze kan dan doorverwijzen naar andere servers, vanaf waar weer doorverwezen kan worden naar andere servers, etc., totdat uiteindelijk een server bereikt is die het [[antwoord]] weet of weet dat de lookup niet mogelijk is. Van dit laatste kan sprake zijn indien de naam niet bestaat of de servers niet reageren. Het proces van het langslopen van verschillende authoritative servers heet recursie.
| |
| | |
| Bij het opzoeken van een domein wordt begonnen op het hoogste niveau (''root'' genaamd) en daarna wordt steeds specifieker gezocht. Bij het zoeken naar een domein wordt meteen aan de DNS-rootserver gevraagd voor bijvoorbeeld <tt>nl.wikisage.org</tt>. Er is geen tussenstap waarbij alleen om <tt>org</tt> gevraagd wordt. Het is immers theoretisch mogelijk dat de rootserver zelf al het antwoord voor <tt>nl.wikisage.org</tt> weet. Zo weten rootservers bijvoorbeeld wel het antwoord voor <tt>a.root-servers.net</tt>. In de regel zal door de DNS-rootserver echter wel verwezen worden naar de nameservers voor <tt>org</tt>. Deze zou in het geval van <tt>nl.wikisage.org</tt> dan verwijzen naar de nameservers voor <tt>wikisage.org</tt> die vervolgens het antwoord weten.
| |
| | |
| Deze servers waar de recursor vragen aan kan stellen zijn de ''authoritative nameservers''. Deze zijn ook relatief dom en geven simpele antwoorden. Deze antwoorden zijn vaak in bestanden of in een [[database]] opgeslagen. Een authoritative nameserver kan een antwoord geven, wat zowel een verwijzing naar een andere server of een direct antwoord op de vraag kan zijn.
| |
| | |
| Zowel de recursor als de authoritative nameserver worden vaak DNS-server genoemd. Het is mogelijk om deze beide functies te combineren in één programma. Dit wordt bijvoorbeeld gedaan in [[BIND]], een van de bekendste en meest gebruikte DNS-servers.
| |
| Er bestaan ook programma's die slechts een van beide functies vervullen. [[NSD]] is een voorbeeld van een puur authoritative nameserver. Bij programma's die beide functies combineren, is het vaak mogelijk om een van beide uit te schakelen of alleen open te stellen voor het interne netwerk.
| |
| | |
| === Caching ===
| |
| Om te voorkomen dat recursors zeer regelmatig overbodige query's doen (DNS-data verandert relatief weinig) hoort een recursor ''caching'' te implementeren.
| |
| Dit wil zeggen dat een eenmaal ontvangen antwoord enige tijd bewaard wordt. Deze tijd kan de beheerder per record aanpassen en wordt [[Time to live]] (TTL) genoemd. In de regel ligt deze tussen enkele minuten en enkele dagen.
| |
| | |
| === Redundantie ===
| |
| In de regel zijn er meerdere authoritative servers voor dezelfde data. Dit om de mogelijke gevolgen van het uitvallen van een server te beperken.
| |
| | |
| In principe moet een recursor, als geconstateerd wordt dat een bepaalde authoritative server niet werkt, alle andere proberen. Uiteindelijk zal er een gevonden worden die wel werkt, of kan de recursor concluderen dat het niet mogelijk is om de naam te resolven.
| |
| | |
| === Resource records ===
| |
| Data in DNS wordt opgeslagen in een ''Resource Record''. Zo'n resource record bevat een type, een TTL, een naam en data. De data kan bijvoorbeeld een IP-adres zijn of een andere naam. Dit is afhankelijk van het type van het resource record.
| |
| | |
| Veel voorkomende types zijn:
| |
| *<tt>A</tt> voor het bepalen van het [[Internet Protocol Version 4|IPv4]]-adres bij een naam
| |
| *<tt>AAAA</tt> voor het bepalen van het [[Internet Protocol Version 6|IPv6]]-adres bij een naam
| |
| *<tt>PTR</tt> voor het bepalen van een naam bij een IPv4- of IPv6-adres (zie verder bij ''reverse lookups'')
| |
| *<tt>MX</tt> voor het bepalen van de [[mailserver]]s voor een domein, waarbij elke mailserver een eigen prioriteit toegewezen krijgt
| |
| *<tt>NS</tt> voor het aangeven welke nameservers de authoritative nameservers zijn (ook gebruikt voor het verwijzen naar andere nameservers)
| |
| *<tt>TXT</tt> aanvankelijk gebruikt voor ieder door de gebruiker gewenst commentaar. Nu mede in gebruik door het SPF anti-spam initiatief.
| |
| *<tt>SRV</tt> een relatief nieuwe record die gebruikt wordt om services aan te duiden.
| |
| | |
| === Omgekeerde lookups ===
| |
| Omgekeerde of "reverse" lookups kunnen dienen om te weten te komen welke naam bij een IP-adres hoort.
| |
| Voor het bepalen van de naam bij een IPv4- of IPv6-adres heeft DNS een op het eerste gezicht ingewikkelde constructie. Voor het bepalen van een naam bij een IPv4-adres, moet men de juiste naam opvragen die zich bevindt onder <tt>in-addr.arpa</tt>.
| |
| | |
| Voorbeeld: <tt>1.2.3.4</tt> wordt vertaald naar <tt>4.3.2.1.in-addr.arpa</tt>. En <tt>52.61.63.53</tt> wordt vertaald naar <tt>53.63.61.52.in-addr.arpa</tt>.
| |
| Voor deze naam (deze naam is vanuit DNS-perspectief niet veel anders dan een naam als <tt>wikisage.org</tt>) wordt het PTR-record opgevraagd. Hieruit komt vervolgens de naam behorend bij het IP-adres.
| |
| | |
| Voor IPv6 is dit vergelijkbaar, maar veel langer en de records bevinden zich in <tt>ip6.arpa</tt>. De reverse van bijvoorbeeld <tt>2001:200:0:8000::42</tt> kan worden verkregen door het opvragen van het PTR-record voor <tt>2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa</tt>.
| |
| | |
| === Nameserver tools ===
| |
| Voor het effectief beheer van een nameserver zijn verschillende diagnostische ''tools'' beschikbaar. De zogeheten [[BIND]]-tools zijn de bekendste. Hieronder vallen bijvoorbeeld ''nslookup'', ''host'' en ''dig''.
| |
| | |
| == Externe links ==
| |
| | |
| '''Enkele DNS-[[Request For Comments|RFC]]'s (er zijn er nog vele andere met aanpassingen en toevoegingen)'''
| |
| *[http://www.ietf.org/rfc/rfc1034.txt RFC1034]: Domain names - concepts and facilities
| |
| *[http://www.ietf.org/rfc/rfc1035.txt RFC1035]: Domain names - implementation and specification
| |
| *[http://www.ietf.org/rfc/rfc1912.txt RFC1912]: Common DNS Operational and Configuration Errors
| |
| *[http://www.ietf.org/rfc/rfc2182.txt RFC2182]: Selection and Operation of Secondary DNS Servers
| |
| '''overige links'''
| |
| *[http://whois.domaintools.com/ DNS look up pagina]
| |
| *[http://www.openspf.org/ Sender Policy Framework]
| |
| | |
| [[Categorie:Internet]]
| |
