Wikisage is op 1 na de grootste internet-encyclopedie in het Nederlands. Iedereen kan de hier verzamelde kennis gratis gebruiken, zonder storende advertenties. De Koninklijke Bibliotheek van Nederland heeft Wikisage in 2018 aangemerkt als digitaal erfgoed.
- Wilt u meehelpen om Wikisage te laten groeien? Maak dan een account aan. U bent van harte welkom. Zie: Portaal:Gebruikers.
- Bent u blij met Wikisage, of wilt u juist meer? Dan stellen we een bescheiden donatie om de kosten te bestrijden zeer op prijs. Zie: Portaal:Donaties.
Dns
Sjabloon:Internetprotocollen Het Domain Name System oftewel DNS is het systeem en protocol dat op het Internet voornamelijk gebruikt wordt om domeinnamen naar IP-adressen te vertalen en omgekeerd.
Een DNS-server of Domain Name Server is op deze technologie gebaseerd, en maakt deze vertalingen, zodat computers niet alleen via het (onpraktische) IP-adres benaderd kunnen worden, maar ook via een hostname (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 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. SPF is één van de instrumenten die zijn ingezet ter bestrijding van wereldwijde spam.
Geschiedenis
Het leggen van een verbinding tussen IP-adres en naam werd oorspronkelijk gedaan met een bestand. Naarmate 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 hosts(.txt). 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 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-afgeleiden bekende /etc/hosts).
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 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 nl.wikisage.org. Er is geen tussenstap waarbij alleen om org gevraagd wordt. Het is immers theoretisch mogelijk dat de rootserver zelf al het antwoord voor nl.wikisage.org weet. Zo weten rootservers bijvoorbeeld wel het antwoord voor a.root-servers.net. In de regel zal door de DNS-rootserver echter wel verwezen worden naar de nameservers voor org. Deze zou in het geval van nl.wikisage.org dan verwijzen naar de nameservers voor wikipedia.org 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:
- A voor het bepalen van het IPv4-adres bij een naam
- AAAA voor het bepalen van het IPv6-adres bij een naam
- PTR voor het bepalen van een naam bij een IPv4- of IPv6-adres (zie verder bij reverse lookups)
- MX voor het bepalen van de mailservers voor een domein, waarbij elke mailserver een eigen prioriteit toegewezen krijgt
- NS voor het aangeven welke nameservers de authoritative nameservers zijn (ook gebruikt voor het verwijzen naar andere nameservers)
- TXT aanvankelijk gebruikt voor ieder door de gebruiker gewenst commentaar. Nu mede in gebruik door het SPF anti-spam initiatief.
- SRV 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 in-addr.arpa.
Voorbeeld: 1.2.3.4 wordt vertaald naar 4.3.2.1.in-addr.arpa. En 52.61.63.53 wordt vertaald naar 53.63.61.52.in-addr.arpa. Voor deze naam (deze naam is vanuit DNS-perspectief niet veel anders dan een naam als wikisage.org) 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 ip6.arpa. De reverse van bijvoorbeeld 2001:200:0:8000::42 kan worden verkregen door het opvragen van het PTR-record voor 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.
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-RFC's (er zijn er nog vele andere met aanpassingen en toevoegingen)
- RFC1034: Domain names - concepts and facilities
- RFC1035: Domain names - implementation and specification
- RFC1912: Common DNS Operational and Configuration Errors
- RFC2182: Selection and Operation of Secondary DNS Servers
overige links