DNS, hoe het werkt en waarom het zo belangrijk is

Een van de mooiste, krachtigste en meest robuuste protocollen in de netwerk wereld is DNS. Helaas wordt het vaak verkeerd of slecht ingezet.

Met dit artikel hoop ik duidelijk te kunnen maken waarom DNS zo mooi is en wat duidelijkheid te verschaffend over het hoe en waarom van DNSSEC.

Wat is DNS?

DNS staat voor Domain Name System, een systeem dat domein namen vertaal naar objecten/gegevens.

Vergelijk het met adressering in ons dagelijks gebruik bij adressen.  Je wilt iets bezoeken, bijvoorbeeld Xillion.  Om er te komen hebben we de locatie nodig, dat is  50°55’21.28″ Noorderbreedte,   5°45’2.62″ Oosterlengte. Gelukkig hebben we iets eenvoudigs ontwikkeld, het adres (Marktplein 8, 6243BR, Geulle, Nederland). Het adres heb je dus nodig om bij een locatie uit te komen. Een adres voert je, van achter naar voren gelezen, naar een locatie toe door op verschillende niveaus een relevante verwijzing te geven (Land = Nederland, Plaats = Geulle, etc).

Op netwerken hebben we ook (IP)-adressen, in combinatie met routes en uiteindelijke de onderliggende MAC-adressen kan een IP pakket zijn doel vinden/bereiken. Maar omdat het inhouden en onderscheiden van al deze adressen niet handig werkt er is DNS ontwikkeld.

Geschiedenis

In jaren 70 van de vorige eeuw ontstond het ARPANET, de voorlopen van het internet. Hierop werkte men met (ip) adressen. Om ook namen te kunnen gebruiken werd er een bestand (host.txt) ingevuld waarin alle computers van het ARPANET benoemd werden. SRI-NIC onderhield dit bestand en zorgde voor de distributie (ze boden het ter download aan).

Naarmate het ARPANET groeide werd het bestand dus ook steeds groter wat met de destijds beschikbare verbindingen en servers al snel in performance- en stabiliteitsproblemen resulteerde, niet iedereen had tijdig de beschikking over de juiste versie van heb host.txt bestand. Omdat er nog geen (hiërarchische) structuur in de naamgeving van computers zat ontstonden er ook al snel dubbele namen.

In 1983 werd door Paul Mockapetris DNS voor het eerst beschreven in RFCs 1034 en 1035. Hierop volgend later een groot aantal updates.

Uitgangspunten

Bij het ontwikkelen van DNS heeft men vast gehouden aan een aantal principes die nu nog steeds de kracht van DNS borgen.

  • Globaal gedistribueerd, data wordt lokaal onderhouden maar kan wereldwijd opgehaald worden. Er is niet één computer die alle DNS data heeft. Ieder apparaat kan vragen stellen aan het DNS. Externe data wordt gecached om prestaties te verbeteren.
  • Loose Coherency, het DNS systeem is altijd in een (intern) consistente toestand. Door het vastleggen van versie nummers voor delen van het DNS (zones). Het versie nummer wordt bij iedere wijziging opgehoogd. Wijzigingen in de master database (zone) worden, volgens timing die de administrator vast legt, gerepliceerd. Data in caches verloopt ook volgens time-out die de zone administrator vast gelegd heeft.
  • Schaalbaar, geen database omvang limiet, geen beperkingen in het aantal bevragingen dat gedaan kan geworden. Dit door automatische distributie via master, slave en cache systemen.
  • Hoge beschikbaarheid, redundant, data is gekopieerd naar meerdere servers. Clienten kunnen contact leggen met zowel master als slave servers. Clienten zullen voor de lokale cache aanspreken. Zolang er iemand antwoord kan geven komt er antwoord.
  • Dynamisch, het is mogelijk om de (master) database dynamisch bij te werken  Iedere update van de master genegeerd een replicatie.

Concepten

Het volgen van bovenstaande uitgangspunten heeft geleid tot een aantal concepten die we terug zien het ontwerp van DNS.

  • Naamgeving DNS Boom

DNS werkt hiërarchisch, hiermee wordt val de schaalbaarheid opgevangen. Een Fully Qualified Domein Name (FQDN) zie er bijvoorbeeld als volgt uit: “www.xillion.nl.” Let daarbij ook op de afsluitende punt. Een FQDN biedt verwijzingen naar verschillende typen objecten.

Domein namen kun je in een boom weer gegeven. Iedere punt in de naam biedt de mogelijkheden voor verdere vertakkingen. DNS kent geen beperkingen aan het aantal aftakkingen. Een domein naam is een ‘namespace’. In het voorbeeld hiernaast: alles onder .com. is het .com-domein. alles onder ripe.net. is het ripe.net domein binnen het .net domein.

Binnen een domein kunnen beheerders sub domeinen toewijzen aan andere computers. Beheerders kunnen ook de verantwoordelijkheid voor een subdomein aan iemand anders toewijzen, maar dat is niet verplicht.

Domeinen zijn administratieve zones waarvoor de domeinbeheerder verantwoordelijk is. Deze verantwoordelijkheid wordt vanuit het bovenliggende niveau toegewezen.

 

 

 

  • Servers

Er zijn 3 rollen DNS servers te beschrijven, master (hoofdserver van een zone, waarop je wijzigingen publiceert), slave (repliceert van de master) en caching/forwarders. De master en slave rollen zijn ‘Authoritative’ rollen, deze stellen DNS data ter beschikking aan het netwerk als deel van grote wereldwijde database. De caching of forwarder rol doet zoekt in de wereldwijde database voor eind gebruikers. De meeste ISPs stellen forwarders aan hun klanten beschikbaar, daarnaast zijn er verschillende ‘open’ alternatieven zoals DNS servers van Google of opendns.

Binnen het DNS-protocol is vast gelegd hoe de replicatie tussen master, slave en de cache werkt. Hierdoor is het mogelijk dat verschillende bedrijven en instellingen (waaronder Microsoft, ISC, PowerDNS, NLNet Labs, Nominum) DNS server ontwikkelen die met elkaar kunnen samenwerken. Het is dan ook perfect mogelijk om bijvoorbeeld een PowerDNS Master te hebben en ISC en Nominum op de slave servers te draaien terwijl je Microsoft DNS gebruikt voor het opzoeken (forwarder).

  • Opvragingen

Een resolver gaat het DNS systeem bevragen in opdracht van een applicatie. In dit proces is op veel systemen (inclusief Windows 2008 R2) nog steeds het principe van het host.txt bestand uit de jaren 70 terug te vinden, hierin wordt als eerste snel gekeken. Als er in de hostfile geen antwoord staat wordt dit verder gegevens aan een resolver/caching DNS server (1). Als deze het antwoord nog niet kent gaat hij dit opvragen de de root (“.”) (2). De root zal aangegeven dat hij de verantwoordelijkheid voor het gevraagde domein gedelegeerd heeft aan een andere computer (3). De resolver zal dan weer contact zoeken met onderliggende zone en daar opnieuw vragen (4). Via nog een delegatie (5) komt de resolver eindelijke bij een authoritatieve server (master of slave) uit (6) en krijgt antwoord (7) die wordt weer terug gegeven aan de applicatie (8).

  •  Records

DNS kan antwoord gegeven een veel verschillende vragen, hiervoor zijn verschillende soort records vastgesteld. Veel gebruikt is het Adres-record, hierin wordt een IP adres opgeslagen.

Record-typeOmschrijvingVoorbeeld
AIP Adreswww.xillion.nl. A 77.93.77.4
CNAMEAlias voorwww.xillion.be. CNAME www.xillion.nl
NSNameserverwww.xillion.nl. IN NS a.ns.xillion.nl
MXMail Exchangexillion.nl. IN MX filter1.mx.xillion.nl
PTRPointer77.93.77.4. PTR www.xillion.nl
SOAState of Authorityxillion.nl. IN SOA a.ns.xillion.nl domains.xillion.nl 2012052100 3600 3600 604800 3600
TXTTextxillion.nl. IN TXT “v=spf1 a:mail.xillion.nl/27 -all”
  • Netwerk Protocol

Voor transport van DNS vragen en antwoorden is er initieel gekozen voor het UDP protocol, dit in plaats van het tegenwoordig gebruikelijke TCP. TCP wordt tegenwoordig door de meeste DNS server ook ondersteunt, dit vooral om IPv6 optimaal te ondersteunen. Daarnaast is TCP, in tegenstelling tot UDP, een sessie gebaseerd protocol, waarbij het beduidend moeilijker is om een DNS spoofing toe te passen. Omdat er bij UDP geen sessie statussen moeten worden bijgehouden is het een beduidend lichter voor de servers, echter op de performance die server tegenwoordig kunnen leveren is de extra belasting van TCP bijna verwaarloosbaar.

  • Robuustheid

Het mooie van DNS is dat zolang er minimaal één authoritieve server functioneel is het volledige principe van DNS nog werkt.  Door gebruikt te maken van verschillende besturingssystemen en DNS-software op verschillende netwerken en in verschillende datacenters voor master en slave servers is het met DNS niet moeilijk om een 100% beschikbaarheid te kunnen realiseren. Mocht er toch een volledige storing bij de master en slave servers dan is de kans nog altijd groot dat de DNS cache van verschillende providers de klanten nog van antwoorden kan voorzien. Veel diensten, zoals bijvoorbeeld e-mail, reageren met een definitieve fout als de DNS niet werkt, terwijl het uitvallen van een e-mail server alleen maar tot vertraging leidt.

 DNSSEC

DNSSEC is beveiligde opvolger van DNS dat ondertussen door het merendeel aan servers en clients al ondersteund wordt. Bij DNSSEC wordt een DNS antwoord voorzien van een digitale handtekening waarmee gecontroleerd kan worden of het antwoord van legitime bron komt.

DNS clients met DNSSEC ondersteuning eisen een DNSSEC antwoord als DNSSEC voor het betreffende domein geactiveerd is, als het domein nog geen DNSSEC heeft accepteren ze ‘gewone’ DNS antwoorden.

DNSSEC voorkomt DNS spoofing (ook wel bekend als de Kaminsky-aanval).  Nadat het gevaar voor spoofing al in 1990 ontdekt werd is het protocol is al in 1995 beschreven en in 1999 definitief vast gelegd in RFC2535.  Uiteindelijk wordt er in 2005 nog een verbeterde versie van DNSSec vastgelegd in 3 RFC’s 4033, 4034, 4035 waarna Sweden (.SE) in Oktober 2005 als eerste DNSSEC activeert.

  • Voordelen

Grootste voordeel aan DNS Sec is uiteraard de beveiliging en controle van DNS antwoorden.

Daarnaast wordt er door DNSSec ‘fans’ ook veelvuldig aangegeven dat DNS, met de DNSSEC uitbreiding, ook bruikbaar wordt voor het distriburen en controleren van allerlei andere gegevens zoals bijvoorbeeld server certificaten (SSL), deze extensie wordt DANE genoemd.

  • Nadelen

DNSSec maakt van DNS een complexere operatie, waarbij een kleine fout of storing er voor kan zorgen dan je domein tijdelijk niet bestaat.

DNS verliest iets van zijn robuustheid, het is dus veiligheid versus beschikbaarheid.

  • Kanttekeningen

DNSSEC fans zien beveiligde domeinen als vertrouwensrelatie die betrouwbaarder is als een Certificate authority (het diginotar debakel heeft flink aan die visie geholpen). Feit wil echter dat de meeste TLDs (zoals in .NL beheert door SIDN) nooit 100% betrouwbare controles op de identiteit van de domein eigenaar hebben gedaan (Laat staan dat een zone zoals .NL dit voor al zijn 5 miljoen domeinen met terugwerkende kracht gaat doen). Met de invoering van IDN (Internationalized Domain Names), het toestaan van niet ASCII tekens in domein namen, kan het voor de eindgebruiker moeilijk worden om het verschil tussen de echte site van bijvoorbeeld een bank en een nep site te herkennen. met DANE wordt het dan zelfs mogelijk om een geldig certificaat op de net site te zetten.