Thuis
Contacten

    Hoofdpagina


2. Wat is dns nou eigenlijk?

Dovnload 130.41 Kb.

2. Wat is dns nou eigenlijk?



Datum26.04.2017
Grootte130.41 Kb.

Dovnload 130.41 Kb.


1. DNS met BIND

Deze handleiding helpt je met het opzetten van een DNS-server met Bind versie 9. De handleiding is toegespitst op het inzetten van bind in een klein netwerk met één server en een aantal werkstations. Toch beschrijf ik een iets groter netwerk, met twee nameservers. Hopelijk komt dit ten goede aan het begrip van de werking van DNS.

Deze handleiding is gericht op mensen die al enige ervaring hebben met Linux of Unix. Zorg dat je ongeveer weet wat DNS is, hoe een editor werkt, hoe je services start, enz.

Verreweg de meeste dingen die ik hier bespreek zullen onder bind 8.2.x ook werken. Onder eerdere versies zal minder functionaliteit aanwezig zijn.



2. Wat is DNS nou eigenlijk?

Simpel gezegd: DNS (het domain name system) is het systeem dat ervoor zorgt dat namen worden omgezet in IP-adressen en IP-adressen weer in namen. Maar dat is iets te simpel. DNS doet nog veel meer dan dat. Over het algemeen gezegd worden er in DNS gegevens over domeinnamen opgeslagen. Dit kunnen IP-adressen zijn, maar ook namen van mailservers en zelfs vrije tekst.

DNS is een flexibel, hiërarchisch, gedistribueerd en redundant systeem. Juist. Voor de mensen die nog niet afgehaakt zijn nu: dat klinkt ingewikkelder dan het is.

Flexibel: Het is mogelijk om vele soorten informatie op te slaan in DNS.

Hiërarchisch: DNS is georganiseerd vanaf een hoogste punt, de DNS root. Onder de root liggen de zogenaamde toplevel domeinnamen zoals 'be', 'com' en 'org'. Daar weer onder liggen de second level domeinnamen zoals 'linux' onder 'org'. Een ook daar weer onder liggen domeinnamen.

Gedistribueerd: elk subdomein kan op zijn eigen nameserver draaien. Het is dus niet nodig om alle informatie centraal op te slaan.

Redundant: elk domein behoort meerdere nameservers te hebben. De DNS root heeft er bijvoorbeeld 13 en het domein 'com' heeft er op het moment van schrijven 7. Kleine en middelgrote domeinen hebben meestal twee nameservers.

DNS is opgebouwd uit zones, die elk één of meerdere (sub)domeinen kunnen bevatten.



3. Bestandslocaties

Voor we aan het echte werk beginnen, even wat over bestandslocaties. De locaties van de bestanden zijn afhankelijk van het al dan niet chrooten van de server. Dit zorgt voor een grotere beveiliging, maar is iets lastiger op te zetten. Lees het hoofdstuk over beveiliging voor meer informatie.


In een normale configuratie zonder chroot gebruiken we de volgende bestandslocaties:

  • Configuratie: /etc/named.conf

  • Zonefiles: /var/named/zones/

Dit is echter sterk afhankelijk van de gebruikte distributie. Debian gebruikt bijvoorbeeld /etc/bind/named.conf en /etc/bind/. Over het algemeen is het verstandig om de voorkeuren van de gebruikte distributie over te nemen, in plaats van de hier gegeven bestandslocaties.

In een chrooted configuratie gebruiken we de volgende bestandslocaties:



  • Configuratie: /var/named/etc/named.conf

  • Zonefiles: /var/named/zones/

In veel setups is het gebruikelijk om zonefiles (bestanden die gegevens bevatten over domeinen, later meer hierover) te plaatsen in /var/named/ en niet in /var/named/zones/. In de praktijk werkt dit echter niet erg handig, vooral wanneer bind chrooted draait (wat uiteraard de voorkeur heeft, uit veiligheidsoogpunt). Maak daarom de directory zones/ in /var/named/ aan.

4. Caching nameserver

De eerste stap van het opzetten van bind is het opzetten van een zogenaamde caching nameserver, ook wel recursieve nameserver genoemd. In deze setup gaat de nameserver op zoek naar gegevens bij andere nameservers. Ik zal niet te diep ingaan op de werking: het gaat er nu even om dat we snel een werkende nameserver krijgen.



4.1 De configuratie

We maken gebruik van de volgende named.conf, die de basis zal zijn voor alle verdere configuratie:



/* Onderstaande Access Control List bevat een lijst met
IP-ranges die in prive netwerken gebruikt worden. Pas deze lijst zo
aan dat je eigen ranges erin opgenomen zijn. */

acl "local_net" {


localhost;
10/8;
172.16/12;
192.168/16;
};

options {


/* voor chroot: /zones */
directory "/var/named/zones";
auth-nxdomain no;
recursion yes;

allow-recursion {


local_net;
};

allow-transfer {


none;
};
};

// generic zones

zone "." {
type hint;
file "root.hint";
};

zone "localhost" in {


type master;
file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" {


type master;
file "127.0.0.zone";
};

Vaak zul je overigens de standaardconfiguratie die door je distributie wordt meegeleverd grotendeels kunnen overnemen. Met name de secties controls en key overnemen, die kunnen nog goed van pas komen later.

Deze configuratie heeft drie bestanden nodig, die waarschijnlijk al staan in /var/named/. Verplaats deze naar /var/named/zones/. De bestanden zijn:



  • root.hint: heet soms ook named.root of db.root

  • localhost.zone: ook wel db.localhost of db.local

  • 127.0.0.zone: ook wel db.127.0.0 of db.127

Dat is alles! Start bind (afhankelijk van de distributie, vaak met /etc/init.d/named start) en probeer wat dingen uit:

  • host localhost 127.0.0.1: moet opleveren: "localhost. has address 127.0.0.1"

  • host 127.0.0.1 127.0.0.1: moet opleveren: "1.0.0.127.in-addr.arpa. domain name pointer localhost."

  • host be.linux.org 127.0.0.1: moet opleveren: "be.linux.org. has address 131.211.28.48"

host is een van de diagnostische tools van bind. Meer over deze tools in de bijlage over tools.

4.2 Configuratie van de werkstations

Nu bind draait, kunnen de werkstations zo geconfigureerd worden dat ze gebruik maken van de vers opgezette server. Pas hiertoe /etc/resolv.conf aan:



nameserver 10.0.0.1

Vaak zal eerst /etc/hosts geraadpleegd worden voor DNS. Pas eventueel de "hosts"-regel aan in /etc/nsswitch.conf:

hosts: files dns

5. Authoritative nameserver

In het vorige hoofdstuk hebben we een caching oftewel recursieve nameserver opgezet. Deze kan nu worden uitgebreid met enkele zones waarvoor de server authoritative is.



5.1 Over zones en domeinen

Bind werkt met zogenaamde zones. Een zone kan informatie over een of meerdere domeinen bevatten. Een zone example.com kan bijvoorbeeld de volgende gegevens bevatten:



  • Het adres van www.example.com, dat valt binnen het domein example.com

  • Het adres van www.sales.example.com, dat valt binnen het domein sales.example.com

  • Een verwijzing naar de nameserver van office.example.com, die de zone office.example.com beheert.

Een zone kan dus gegevens bevatten over vele subdomeinen, maar hij kan ook zones delegeren naar andere nameservers, door middel van NS-records.

5.2 Over Resource Records

Een zone bestaat uit zogenaamde resource records, afgekort als RR. Elk RR heeft een naam, een type en een waarde. Eigenlijk heeft elk RR ook nog een klasse, maar in de praktijk vallen alle RR's onder de klasse IN, van InterNet.

Bijna alle RR's kunnen meerdere waardes en/of types onder dezelfde naam hebben. Zo is het bijvoorbeeld mogelijk meerdere IP-adressen te koppelen aan dezelfde naam, wat zorgt voor een spreiding van de belasting. Bind zal die adressen in een roterende volgorde uitgeven, zodat bij elke aanvraag een ander adres als eerste gezien wordt. Zo'n serie records met dezelfde naam en type heet een RRset. Het is niet mogelijk om een specifiek record op te vragen: een client vraagt altijd om een RRset.

De belangrijkste typen resource records zijn:



A
Koppelt een IPv4-adres aan een naam

AAAA
Koppelt een IPv6-adres aan een naam

PTR
Koppelt een naam aan een IPv4-adres, zie Reverse Lookups

CNAME
Koppelt een naam aan een andere naam (alias)

NS
Delegeert een zone naar een andere nameserver

MX
Definieert een zogenaamde Mail eXchanger

SOA
Definieert een Start Of Authority; geeft aan wie autoriteit heeft over een bepaalde zone


De appendix over resource records bespreekt deze in meer detail.

Een voorbeeld

Al geïntimideerd? Dan maar snel een voorbeeld om alles wat duidelijker te maken:



$TTL 1D
example.com. IN SOA ns.example.com. erik.example.com. (
2003040901
4H
2H
4W
1D )

IN NS ns.example.com.


IN MX 10 mail.example.com.
IN MX 100 mailbackup.provider.net.
IN A 10.0.0.1

$ORIGIN example.com.

ns IN A 10.0.0.2
www IN A 10.0.0.1
ftp IN CNAME www.example.com.
mail IN A 10.0.0.3
office IN NS ns.office.example.com.
ns.office IN A 10.0.1.1


Wat betekent dat nou allemaal? Alle namen zijn relatief ten opzichte van de zone, tenzij ze worden afgesloten met een punt. In dat geval zijn het absolute namen.

Ik loop stap voor stap door de zonefile heen:

$TTL 1D: dit is geen resource record, maar een indicatie dat deze gegevens maximaal 1 dag mogen worden opgeslagen in een caching nameserver voordat die server de RR opnieuw moet opvragen. Hierover later meer.

example.com. IN SOA [...]: het eerste resource record van een zonefile moet altijd van het type SOA zijn. Er staat hier dat er een RR is met de naam example.com., van de klasse IN en het type SOA met de waarde SOA ns.example.com. [...]. Over de precieze betekenis van alle velden in het SOA-record later meer.

IN NS ns.example.com.: geen naam voor dit record. Hij neemt dan automatisch de naam van het vorige record over: example.com.. Dit is een RR van het type NS, die aangeeft dat de nameserver voor deze zone ns.example.com. is.

IN MX 10 mail.example.com.: example.com heeft twee mailservers: mail.example.com en mailbackup.provider.net. Het getal geeft de 'kostenfactor' aan: een MTA zal altijd proberen mail af te leveren op de MX met de laagste kosten (in het engels heet dit preference).

IN A 10.0.0.1: tenslotte heeft example.com het adres 10.0.0.1.

Hierop volgt ten overvloede de regel $ORIGIN example.com., die aangeeft dat alle namen relatief ten opzichte van example.com. zijn.



ns IN A 10.0.0.2: ns.example.com heeft adres 10.0.0.2.

ftp IN CNAME www.example.com.: ftp.example.com is een alias voor www.example.com.

office IN NS ns.office.example.com.: aanvragen voor adressen binnen de zone office.example.com moeten gaan naar de computer met de naam ns.office.example.com.

ns.office IN A 10.0.1.1: tenslotte geeft deze regel aan dat het adres van ns.office.example.com 10.0.1.1 is.

Het SOA-record

Elke zone moet een SOA-record hebben. Hierin staat aangegeven welke nameserver de autoriteit is over deze zone en het e-mailadres van de beheerder van die zone. Ook staat er informatie die door slaveservers gebruikt kan worden (zie het hoofdstuk over slaveservers). Het SOA-record moet ook de eerste RR zijn in een zonefile.

Het SOA-record ziet er als volgt uit:


SOA (




)

is de naam van de nameserver die de primary master is. Voor een zone kunnen meerdere nameservers authoritative zijn, maar er is altijd precies één primary master.

Het e-mailadres van de beheerder kan geen apenstaartje bevatten: vervang die door een punt. De eerste punt in de naam kun je weer vervangen door een @ om een geldig e-mailadres te krijgen. In het voorbeeld is erik@example.com dus de beheerder.

is het serienummer van de zonefile. Zodra een slaveserver ziet dat de primary master een hoger serienummer heeft voor een zone, zal hij zijn gegevens verversen. Het serienummer is niet meer dan dat: een nummer. De meeste beheerders verwerken de datum en een volgnummer in het serienummer, als volgt: jjjjmmddnn. nn is hierbij het volgnummer binnen een dag. Voorbeeld: de derde versie van een zonefile geschreven op 17 april 2003 zou serienummer 2003041703 krijgen.

Vergeet niet om bij elke aanpassing het serienummer te verhogen. Doe je dat niet, dan zal bind hem niet opnieuw inlezen en ook na een herstart (als bind hem dus wel leest) zullen slaves de zone niet overnemen.

Op de rest van de gegevens in het SOA-record ga ik verder niet in. De waarden zoals gegeven in het voorbeeld zijn voor bijna iedereen bruikbaar.

5.3 Configuratie in named.conf

Als je een zonefile hebt gemaakt en opgeslagen in bijvoorbeeld /var/named/zones/db.example.com, dan moet hij nog in de nameserver geladen worden. Dat kan door het volgende fragment toe te voegen aan named.conf:



zone "example.com" {
type master;
file "db.example.com";
};

Herstarten van bind

Het is niet nodig om bind te stoppen om een nieuwe zonefile te laden, of zelfs maar om named.conf opnieuw te laden. Er zijn twee manieren om alles opnieuw te laden:



  • Het versturen van een HUP signaal naar de server: killall -HUP named

  • Met de utility rndc: rndc reload.

Die laatste methode heeft wel wat extra configuratie nodig, waar ik hier niet op zal ingaan.

5.4 Over naamgeving van interne zones en domeinen

Als je domein geregistreerd is op internet, dan is de naam ervan duidelijk. Gebruik je echter een naam die alleen voor intern gebruik is, kies dan een naam die nooit op internet kan voorkomen. Gebruik zeker nooit een domein waarvan je weet dat hij voorkomt op internet, zoals bijvoorbeeld het domein van het bedrijf waarvoor je werkt. Als je dat doet, dan krijg je meerdere nameservers die zichzelf authoritative vinden voor die zone. Het is erg makkelijk om op die manier bijvoorbeeld de webserver van je bedrijf onbereikbaar te maken voor iedereen op kantoor.

Ik heb een eigen geregisteerd domein: hensema.net. Binnen dat domein heb ik subdomein home.hensema.net gereserveerd voor gebruik bij mij thuis.

Als je geen eigen geregisteerd domein hebt, gebruik dan het domein home voor interne domeinen. Je computers zouden dan bijvoorbeeld *.hensema.home kunnen gaan heten.



5.5 Caching en TTL

Elk record heeft een zogenaamde time to live of TTL. De TTL bepaald hoe lang caching nameservers een RR mogen opslaan voordat ze hem opnieuw moeten opvragen bij de authoritative server voor het betreffende RR.

De default TTL wordt ingesteld met de $TTL regel in de zonefile, maar kan ook per RR ingesteld worden. Zo kan het verstandig zijn om de TTL van het A-record van een machine die binnenkort een nieuw IP-adres krijgt, te verlagen tot bijvoorbeeld een half uur.

De TTL wordt standaard opgegeven in seconden, maar in zonefiles kun je ook minuten (m), uren (h), dagen (d) of weken (w) opgeven. De TTL in de voorbeelden is bijvoorbeeld 1D oftewel 1 dag.

Het is zelden zinnig om de TTL-waarde veel hoger in de stellen dan 48 uur of lager dan een half uur.

Een voorbeeld van hoe je een TTL instelt voor een RR:



www 1800 IN A 10.0.0.1

Hiermee wordt de TTL op 1800 seconden gezet.

5.6 Wildcard records

Een wildcard record is een RR met alle mogelijke namen. Als je dus vraagt om een RR met het type van een wildcard, dan krijg je altijd zijn waarde terug.

Voorbeeld:


* IN A 10.0.0.2

Als de wildcard binnen example.com zou vallen, dan zal bijvoorbeeld planning.example.com gaan wijzen naar 10.0.0.2.

Gebruik wildcards in principe alleen voor A- of AAAA-records. Gebruik ze zeker niet voor NS-records, tenzij je weet wat je doet. Zo niet, dan kun je in de problemen komen.



6. Reverse lookups

Soms wil je niet alleen het IP-adres bij een naam zoeken, maar ook het omgekeerde: je hebt een IP-adres en je wilt weten welke naam daar bij hoort. Dit heet een reverse lookup.

Omdat je aan een IP-adres niet kunt zien tot welke zone deze behoort, is er een speciale zone waarin alle IP-adressen opgenomen kunnen worden, in-addr.arpa. Het adres wordt geschreven van 'achter naar voren' en gevraagd aan het DNS-systeem: als je de naam van 1.2.3.4 wilt weten, dan zoek je naar 4.3.2.1.in-addr.arpa.

De resource records die namen aan adressen koppelen zijn zogenaamde PTR-records. Net als bij andere RR's is het hierbij mogelijk dat een IP wijst naar meerdere namen. In de praktijk gebeurt dat echter zelden en is het feitelijk ook niet wenselijk.

Aan de hand van het netwerk van example.com zal ik een voorbeeld geven:


$TTL 1D
0.10.in-addr.arpa. IN SOA ns.example.com. erik.example.com. (
2003040901 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
IN NS ns.example.com.
1 IN NS ns.office.example.com.
1.0 IN PTR www.example.com.
2.0 IN PTR ns.example.com.
3.0 IN PTR mail.example.com.

Het netwerk van example.com is 10.0.x.y. Daarbinnen is een opdeling tussen 10.0.0.x voor de webservers en dergelijke en 10.0.1.x voor het kantoor. Ik heb ervoor gekozen om de zone 0.10.in-addr.arpa hiervoor te gebruiken. Het was eventueel ook mogelijk geweest om 10.in-addr.arpa te gebruiken. Die kan meer adressen bevatten, maar dat is vaak eerder een nadeel dan een voordeel.

De zonefile in het voorbeeld bevat de reverses van 10.0.0.x en een delegatie naar ns.office.example.com voor de reverses van 10.0.1.x. Wil je bijvoorbeeld de naam van 10.0.0.2 weten, dan vraag je het PTR-record van 2.0.0.10.in-addr.arpa op, en krijg je als antwoord ns.example.com.

Wil je weten wat de naam van 10.0.1.1 is, dan gaat onze nameserver dat vragen aan ns.office.example.com omdat er een delegatie is opgenomen. Op ns.office.example.com draait de zone 1.0.10.in-addr.arpa (als alles goed is, uiteraard. Zo niet, dan is ns.office.example.com een zogenaamde lame server).

6.1 Delegaties op interne netwerken

In het voorbeeld wordt 10.0.1.x gedelegeerd naar ns.office.example.com. Maar hoe kan die server nou komen achter adressen binnen 10.0.0.*?

Het antwoord is dat ook ns.office.example.com authoritative moet worden voor de zone 0.10.in-addr.arpa. Om te zorgen dat de gegevens van 10.0.0.* niet gedupliceerd hoeven te worden naar de kantoorserver, maken we een nieuwe zone: 0.0.10.in-addr.arpa.

In de zone 0.10.in-addr.arpa komen alleen delegaties te staan naar onderliggende nameservers. Pas in de zones eronder komen de feitelijke PTR-records te staan. De zonefile voor 0.10.in-addr.arpa wordt nu:

$TTL 1D

0.10.in-addr.arpa. IN SOA ns.example.com. erik.example.com. (



2003040901 ; serial

28800 ; refresh (8 hours)

14400 ; retry (4 hours)

3600000 ; expire (5 weeks 6 days 16 hours)

86400 ; minimum (1 day)

)

IN NS ns.example.com.



IN NS ns.office.example.com.

0 IN NS ns.example.com.

1 IN NS ns.office.example.com.

Deze zone moet beschikbaar zijn op alle nameservers binnen het 10.0.x.y netwerk. Hoe dat op een makkelijke manier kan staat uitgelegd in het hoofdstuk over masters en slaves.

ns.example.com kan nu de zone voor 0.0.10.in-addr.arpa gaan draaien:

$TTL 1D


0.0.10.in-addr.arpa. IN SOA ns.example.com. erik.example.com. (

2003040901 ; serial

28800 ; refresh (8 hours)

14400 ; retry (4 hours)

3600000 ; expire (5 weeks 6 days 16 hours)

86400 ; minimum (1 day)

)

IN NS ns.example.com.



1 IN PTR www.example.com.

2 IN PTR ns.example.com.

3 IN PTR mail.example.com.

6.2 Configuratie in named.conf

Tenslotte moeten de reverse zones nog worden opgenomen in named.conf. Op ns.example.com zal dat zoiets worden:

zone "0.10.in-addr.arpa" in {

type master;

file "db.10.0";

};

zone "0.0.10.in-addr.arpa" {



type master;

file "db.10.0.0";

};

6.3 Reverses opvragen met dig



Dig vraagt altijd letterlijk om de opgegeven resource record, de volgende opdracht zal bijvoorbeeld het A-record opvragen van 10.0.0.1:

dig 10.0.0.1

De -x optie geeft aan dat dig moet vragen om een PTR-record en dat hij de data automatisch moet omzetten naar reverse-notatie. De volgende opdracht vraagt om de PTR-record voor 1.0.0.10.in-addr.arpa:

dig -x 10.0.0.1

Host vraagt wel automatisch om een PTR-record als zijn argument lijkt op een IP-adres.

7. Masters en slaves

Door te werken met meerdere nameservers voor dezelfde zone kan de belasting gespreid en de bedrijfszekerheid verhoogd worden. Bind servers zullen automatisch de nameserver gebruiken die het snelst reageert.

Elke zone heeft precies één master en kan meerdere slaves hebben. Elke publieke zone moet in principe minimaal twee authoritative nameservers hebben, dus een master en minstens één slave.

Voor mensen die geen beheerder van een zone zijn (en dat zijn de meeste mensen niet) is het niet mogelijk om te zien welke server een master is en welke server een slave. De enige indicatie is het SOA-record. Vooral voor zogenaamde dynamische updates is het van belang dat de informatie in het SOA-record klopt. Voor een mogelijk gebruik van dynamische updates, zie het hoofdstuk over DHCP.

Om de belasting te verdelen over alle nameserver die authoritative zijn voor een zone, is het van belang om voor elke server een NS-record op te nemen. Externe servers gebruiken deze gegevens om te beslissen welke authoritative server ze gaan aanspreken.

Stel nou dat de verbinding tussen de netwerken 10.0.0.x en 10.0.1.x niet zo heel erg snel is en dat de beheerder van example.com dus graag wil dat zijn zone ook altijd beschikbaar is op ns.office.example.com. In dat geval voegt hij aan zijn zone een extra NS-record toe:

IN NS ns.example.com. /* bestond al */

IN NS ns.office.example.com. /* nieuw toegevoegd */

7.1 Configuratie van de master

De master moet zogenaamde zone transfers toestaan vanaf ns.office.example.com. Dat doet hij door een extra blok toe te voegen aan de zoneconfiguratie in named.conf:

zone "example.com" {

type master;

notify yes;

file "db.example.com";

allow-transfer {

127.0.0.1;

::ffff:127.0.0.1;

10.0.1.1;

::ffff:10.0.1.1;

};

};

Het allow-transfer-blok geeft aan vanaf welke IP-adressen zonetransfers gestart mogen worden. Behalve het adres van de slave is hier ook 127.0.0.1 opgenomen, zodat je ook lokaal kunt testen. In dit geval met: dig axfr example.com @localhost.



Bind is voorbereid op IPv6 en daarom is het van belang om behalve het normale IPv4-adres van de slave ook het zogenaamde compatibility-adres in IPv6-notatie op te nemen. Dit is gewoon het IPv4-adres met ::ffff: ervoor.

Verder is de regel "notify yes;" toegevoegd. Deze regel zorgt ervoor dat de master de slave op de hoogte stelt van updates in de zone, zodat de slave een zonetransfer kan gaan doen. Zonder notify neemt de slave de zone ook wel automatisch over, maar hij controleert dan periodiek voor updates. Deze periode wordt bepaald door het refresh veld in het SOA-record.

7.2 Configuratie van de slave

Configuratie van de slave is redelijk simpel:

zone "example.com" {

type slave;

file "slave/db.example.com";

masters {

10.0.0.2;

};

};



Persoonlijk houd ik het liefst slavezones gescheiden van masterzones, dus plaats ik ze in de directory slave/ binnen /var/named/zones/.

En dat is alles, meer configuratie is er niet nodig op een slave.

8. De DNS root

Zoals je hebt kunnen zien kun je subdomeinen delegeren naar onderliggende nameservers. Maar als er onderliggende servers zijn, dan zijn er ook bovenliggende servers. En waar houdt dat op?

Het houdt op bij de DNS root. De root heeft geen naam, hij wordt aangegeven met een punt. De rootservers (er zijn er 13) weten wat de nameservers zijn voor de toplevel-domeinen, bijvoorbeeld wat de nameservers zijn voor het domein "be.", of het domein "com.".

De namen en adressen van de 13 rootservers zijn bekend bij (zo goed als) alle nameservers. Ook die in ons voorbeeld: root.hint bevat ze alle 13. De lijst is ook op te vragen met het commando host -t ns . (host -t ns punt)

Het hele DNS systeem is opgebouwd vanuit de root. Vanaf de root wordt steeds verder gedelegeerd tot je uiteindelijk uit komt bij een server die authoritative is voor de data die je wilt hebben.

8.1 Glue records

Er is wel een probleem: wat nou als je nou het adres van een nameserver wilt hebben, en je alleen maar de naam van die server weet? En wat nou als nou net die server de enige server is die dat adres weet? Theoretisch? Vraag maar aan de nameserver van com. wat de nameserver is van example.com. Het antwoord zal zijn: ns.example.com. Maar als je het adres van ns.example.com wilt weten, dan zul je toch eerst zijn.... adres moeten weten.

Om deze kip-en-ei situatie op te lossen zijn er glue records. De nameserver van com. weet ook het adres van ns.example.com zodat je keurig doorverwezen kunt worden.

In het voorbeeld komt ook zoiets voor: ns.example.com heeft een delegatie naar ns.office.example.com voor office.example.com, maar ook een A-record voor die naam.

De gegevens in glue records worden op twee plekken opgeslagen: in de delegerende server (oftewel parent server, in dit geval ns.example.com) en in de authoritative server (in dit geval ns.office.example.com). Bind zal de glue records altijd vervangen door data vanaf authoritative servers. Uiteraard moet je zorgen dat de data in beide gevallen hetzelfde is, maar bijvoorbeeld de TTL kan verschillen.

9. Bind en IPv6

Vanaf versie 9 heeft Bind een zeer uitgebreide ondersteuning voor IPv6. Versie 8 heeft slechts een gedeeltelijke ondersteuning voor IPv6.

Bind 9 heeft ondersteuning voor alle huidige IPv6-gerelateerde resource records. Ook kan bind 9 queries antwoorden en verzenden via IPv6.

Ik ga er vanuit dat je al de basiskennis over IPv6 hebt voordat je begint aan dit hoofdstuk.

9.1 Configuratie in named.conf

Om bind te laten luisteren op IPv6 kun je het volgende toevoegen aan het options-blok in named.conf:

listen-on-v6 {

any;


};

Vervang eventueel any door een lijst van IPv6-adressen waaronder de server bereikbaar moet zijn.

9.2 Het AAAA-record

Het AAAA-record is het IPv6 equivalent van het A-record. Hiermee kun je een IPv6-adres toekennen aan een host:

www IN AAAA 3ffe:8280:10:a10::1

9.3 Reverse lookups



De configuratie van reverse zones blijkt nogal lastig te zijn. Toch verschilt het niet zo heel veel van reverses van IPv4-adressen. Er zijn twee echte verschillen:

• delegatie gaat per 4 bits in plaats van per 8 bits. Met andere woorden: per letter of cijfer van het adres.

• de zone valt onder ip6.arpa in plaats van in-addr.arpa.

Stel dat je prefix is: 3ffe:8280:10:a10/60, dan schrijf je die eerst helemaal uit met alle nullen voor de getallen: 3ffe:8280:0010:0a10/60. Vervolgens schrijf je je prefix op van achter naar voren met punten tussen alle getallen: 0.1.a.0.0.1.0.0.0.8.2.8.e.f.f.3. Tenslotte plak je er het domein ip6.arpa erachter, en je hebt de naam van de reverse zone: 0.1.a.0.0.1.0.0.0.8.2.8.e.f.f.3.ip6.arpa.

Voor de adressen binnen die zone gebruik je dezelfde procedure: schrijf alle voorloopnullen uit, keer alles om en je hebt je adres.

Als voorbeeld gebruiken we 3ffe:8280:10:a10::1. Het laatste deel van het adres schrijven we uit tot 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

Maar snel een voorbeeld om dit alles te verduidelijken:

$TTL 1D


@ IN SOA ns.example.com. erik.example.com. (

2003041401

8H ; refresh

2H ; retry

4W ; expire

1D ) ; minimum

IN NS ns.example.com.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.example.com.

In named.conf nemen we op:

zone "0.1.a.0.0.1.0.0.0.8.2.8.e.f.f.3.ip6.arpa" {

type master;

file "db.3ffe:8280:10:a10";

};

ip6.int versus ip6.arpa



Tijdens de ontwikkeling van IPv6 zijn de reverses tijdelijk opgenomen onder ip6.int. Op dit moment is er echter een omschakeling bezig naar ip6.arpa. De meeste libraries maken nog gebruik van het oude domein. Het is dus verstandig om reverses aan te bieden onder beide zones.

Dat gaat heel gemakkelijk met een simpel truukje: neem een extra zonedefinitie op in named.conf, maar maak gebruik van hetzelfde bestand als voor ip6.arpa:

zone "0.1.a.0.0.1.0.0.0.8.2.8.e.f.f.3.ip6.int" {

type master;

file "db.3ffe:8280:10:a10";

};

Om hetzelfde doel te bereiken kun je ook een DNAME-record gebruiken.



Reverses opvragen met dig

Om redenen die later duidelijk zullen worden, moet je de opties "-n -x" meegeven aan dig om reverses van IPv6-adressen op te vragen, als volgt:

dexter:~$ dig -n -x 2001:888:10a1::1

[...]


1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.0.1.8.8.8.0.1.0.0.2.ip6.arpa. 3600 IN PTR dexter.ipv6.hensema.net.

[...]


Afhankelijk van de versie van dig zal hij vragen om een adres binnen ip6.int of ip6.arpa.

In de uitvoer van dig staat ook automatisch het adres in reverse-notatie. Je kunt dig dus ook gebruiken om snel even uit te zoeken wat de reverse van je ingewikkelde IPv6 adres is.

9.4 Geavanceerde technieken

Wat ik tot nu toe beschreven heb is een redelijk simpele uitbreiding op de bestaande IPv4-infrastructuur binnen DNS. Echter, bind ondersteunt ook een aantal dingen die met IPv4 niet mogelijk zijn.

Voor alles wat ik hier bespreek heb je bind 9 nodig.

Meerdere prefixes in hetzelfde netwerk

Wanneer je een groot netwerk moet migreren naar een nieuwe IPv6-prefix, dan loop je tegen het probleem aan dat die prefix op heel veel plekken is opgeslagen, mogelijkerwijs binnen vele zonefiles op meerdere nameservers. Dat geldt niet alleen voor de AAAA-records, maar ook voor de PTR-records.

Bind 9 introduceert twee nieuwe resource records waarmee je de prefix centraal kunt opslaan: A6 en DNAME.

Het A6-record

Het A6-record stelt je in staat om slechts een gedeelte van een IPv6-adres op te slaan en een gedeelte te delegeren naar een symbolische naam die centraal gedefinieerd is.

In het A6-records worden dus drie dingen opgeslagen:

• De prefix lengte in bits. Dit is het aantal bits dat niet gegeven wordt in dit A6-record.

• Een gedeeltelijk adres

• Een symbolische naam die wijst naar het A6-record dat de rest van het adres bevat

Dat klinkt nogal complex, en eerlijk gezegd: dat is het ook. Wees gerust: A6 komt in de praktijk (nog?) niet voor.

Maar wat kun je er nou mee? A6 stelt je in staat om het deel van het adres op te slaan dat je lokaal toekent. De rest laat je toekennen door degene die je een prefix toewijst.

Voorbeeld: office.example.com heeft een 64-bits prefix toegewezen gekregen van de beheerder van example.com, die zelf weer een 48-bits prefix heeft. De zonefile voor office.example.com zou er zo uit kunnen zien:

ws01 IN A6 64 ::1 officenet.example.com.

ws02 IN A6 64 ::2 officenet.example.com.

ws03 IN A6 64 ::3 officenet.example.com.

Hier zijn dus drie werkstations gedefineerd met de onoriginele namen ws01 t/m ws03. De eerste 64 bits van hun adressen kunnen we vinden in officenet.example.com, gedefinieerd in de zonefile van example.com:

officenet IN A6 48 0:0:0:1:: examplenet.provider.net.

De eerste 48 bits zijn niet gegeven en dus op nul gezet.

We weten nu al meer van het adres van ws01: hij eindigt op 1::1.

De provider van example.com stelt de prefix in met bijvoorbeeld:

examplenet IN A6 0 1234:5678:90ab::

Hier zijn 0 bits niet gegeven, oftewel: dit is het begin van een definitie. Er is danook geen symbolische naam gegeven voor verdere delegatie (in werkelijkheid zou provider.net ook weer een prefix krijgen van een bovenliggende provider, maar dit voorbeeld is al lang genoeg zo).

Aldus vinden we ook het volledige IPv6-adres van ws01: 1234:5678:9ab:1::1.

Het DNAME-record

Zoals je misschien wel kunt raden is DNAME de tegenhanger van A6 voor reverse lookups. Gelukkig werkt een DNAME wel wat eenvoudiger.

Een DNAME stelt je in staat om een soort wildcard CNAME te maken. Alle domeinnamen die eindigen op de in de DNAME opgegeven naam worden automatisch vervangen door een andere domeinnaam door middel van een automatisch gegenereerde CNAME.

Stel dat de beheerder van example.com een nieuwe prefix wil toewijzen aan office.example.com. Hij kan de reverse voor de oude prefix dan laten doorverwijzen met een DNAME:

$ORIGIN 0.1.a.0.0.1.0.0.0.8.2.8.e.f.f.3.ip6.int

1 IN DNAME 2

2 IN NS ns.office.example.com.

In een technote van ISC.org staat beschreven hoe je je oude ip6.int zone kunt hernoemen naar een ip6.arpa zone met behulp van een DNAME.

Bitstring labels

Als je A6 en DNAME al te exotisch vond, sla deze paragraaf dan maar over. Bitstring labels kunnen volwassen mannen aan het huilen krijgen. Als troost kan ik vertellen dat bitstring labels in de praktijk nog minder voorkomen dan A6-records.

Een bitstring label is een andere manier van het weergeven van een reverse. Deze kunnen tot op de bit nauwkeurig gedelegeerd worden. In combinatie met DNAME kunnen hier ook weer ketens van delegaties gemaakt worden zodat je uiteindelijk uitkomt bij een volledige reverse.

Aangezien in de praktijk niemand wil delegeren op de bit nauwkeurig (lekker nutteloos als je zo'n overvloed aan adresruimte hebt die IPv6 biedt...), zul je bitstring labels nooit tegenkomen in de praktijk.

Of toch wel. Helaas gebruikt dig automatisch bitstring labels bij het opvragen van reverses. Een simpele "dig -x " zal dus falen. Voeg de optie -n toe om het 'oude' (lees: huidige) nibble-formaat te gebruiken: dig -n -x .

Een bitstring label is een verkorte weergave van een RR dat alleen uit binaire waardes bestaat, dus enen en nullen. De volgende twee RR's zijn functioneel gelijk:

\[x0f/8] IN DNAME ip6.tla.net.

1.1.1.1.0.0.0.0 IN DNAME ip6.tla.net.

Deze records zeggen dat alle adressen die beginnen met 0f gedelegeerd moeten worden naar ip6.tla.net.

Een bitstring label is altijd omgeven door "\[" en "]". Daarop volgt een letter die aangeeft of de label geschreven is in binair (b), octaal (o) of hexadecimaal (x).

De reverse van ws01.office.example.com (1234:5678:9ab:1::1) zou je kunnen weergeven met het volgende label:

\[x1234567890ab00010000000000000001/128] IN PTR ws01.office.example.com.

Uiteraard is het netter om dit ook weer met een keten van DNAMEs op te lossen.

10. Dynamische updates met ISC DHCPd v3.x

Bind kan omgaan met zogenaamde dynamische updates. Hierbij wordt er contact gemaakt met de server en kunnen dynamisch resource records worden toegevoegd, veranderd en verwijderd. Het is niet nodig om direct te schrijven in de zonefile en de server te reloaden.

Dynamische updates zijn erg handig in combinatie met DHCP: de namen en adressen van de uitgegeven leases worden automatisch opgenomen in de DNS-server.

Het gebruik van dynamische updates in een zone heeft wel een nadeel: zodra een zone dynamisch is geworden, zijn handmatige aanpassingen in principe niet meer mogelijk. Omdat het gebruik van de tool nsupdate soms wat lastig is, beschrijf ik een manier om handmatig updates te doen in een dynamische zone. Die is echter "niet netjes".

Gezien het op zijn minst onverstandig is om DHCP te gebruiken op een netwerksegment waar ook web-, name- en mailservers staan, ga ik hier er vanuit dat DHCP draait op het netwerksegment van office.example.com.

10.1 Veilige updates met TSIG

Om een dynamische update veilig uit te kunnen voeren maken we gebruik van een zogenaamde transaction signature oftewel TSIG. Dat is een pseudo-RR waarmee transacties te ondertekenen zijn op basis van een gedeeld wachtwoord (shared secret).

TSIG is onderdeel van de zeer complexe DNS Security Extensions (dnssec). Op dnssec zal ik verder niet ingaan hier.

Aanmaken van de key

Voor het gebruik van dnssec heb je een key nodig. Die is te genereren op de volgende manier:

dexter:~ # dnssec-keygen -a HMAC-MD5 -b 128 -n ENTITY dhcp-key

Kdhcp-key.+157+38469

Dit levert twee bestanden op: Kdhcp-key.+157+38469.key en Kdhcp-key.+157+38469.private. De getallen zullen elke keer anders zijn overigens.

In beide bestanden staat in essentie dezelfde informatie. Het enige wat voor ons van belang is, is de key zelf, die op de regel beginnend met "Key" staat in Kdhcp-key.+157+38469.private:

Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5)

Key: qvRUwdlVvJ9vLGgNqtl46Q==

Gebruik overigens niet de key uit het voorbeeld, maar genereer een eigen key. Je bent gewaarschuwd.

Deze key moeten we bekend maken aan bind en dhcpd.

10.2 Configuratie van bind

De net gegenereerde key kunnen we nu gaan opnemen in named.conf, op de volgende manier:

key "dhcp-key" {

algorithm HMAC-MD5;

secret "qvRUwdlVvJ9vLGgNqtl46Q==";

};

Plaats dat blok onder het options blok. Mocht named.conf leesbaar zijn voor iedereen op het systeem, dan kun je bovenstaande fragment in een apart bestand plaatsen en met include ""; inlezen.



Hierna moet nog worden aangegeven welke zones dynamische updates mogen ontvangen die ondertekend zijn met deze key. DHCPd kan updates doen in de normale en in de reverse zone, dus die gaan we beide toestaan:

zone "office.example.com" {

type master;

file "db.office.example.com";

allow-update {

key "dhcp-key";

};

};

zone "1.0.10.in-addr.arpa" {



type master;

file "db.10.0.1";

allow-update {

key "dhcp-key";

};

};

Na de reload zal bind klaar staan om dynamische updates te ontvangen.



10.3 Configuratie van DHCPd

Aangezien dit een handleiding is voor bind en niet voor DHCPd, ga ik er vanuit dat je al een goed draaiende DHCPd hebt. Voor dynamische updates is wel ISC DHCPd v3.x nodig.

Ik zal volstaan met het geven van de regels die moeten worden toegevoegd of aangepast in dhcpd.conf:

option domain-name "example.com"; # kan ook in subnet blok worden gegeven

key "dhcp-key" {

algorithm HMAC-MD5;

secret "qvRUwdlVvJ9vLGgNqtl46Q==";

};

zone example.com. {



primary 10.0.1.1;

key "dhcp-key";

};

zone 1.0.10.in-addr.arpa. {



primary 10.0.1.1;

key "dhcp-key";

};

Ook hier kun je de key weer via een include-statement inladen.



10.4 Aanpassingen met nsupdate in een dynamische zone

De tool nsupdate kan worden gebruikt om handmatig dynamische updates uit te voeren in een server. In dit geval roep je hem aan met:

nsupdate -k Kdhcp-key.+157+38469.private

Het gaat te ver om hier in te gaan op het verdere gebruik van nsupdate. In de appendix staan een paar voorbeelden.

10.5 Handmatige aanpassingen in een dynamische zone

Mocht het gebruik van nsupdate wat te lastig zijn, dan zijn handmatige aanpassingen in de zonefile nog wel mogelijk.

Om een zonefile weer (tijdelijk) statisch te maken, kun je het volgende doen:

• rndc freeze

• Bewerk de zone

• rndc thaw

11. Beveiliging

De standaard configuratie van bind staat vrijwel alles toe: iedereen mag alle data opvragen en alle data is voor iedereen gelijk. Op het huidige internet is dat niet meer altijd gewenst. Soms is het zelfs niet netjes om iedereen toegang te geven tot alle data: A-records die wijzen naar privé-ranges zoals 10.* zouden niet mogen worden gezien door mensen op het internet.

In dit hoofdstuk bespreek ik twee manieren om je DNS-server te beveiligen: access control en views.

11.1 Access control

Met access control zijn bepaalde acties te beperken voor bepaalde IP-ranges. Dit is in te stellen voor de gehele server of per zone.

Dit zijn de meest belangrijke access controls:

allow-transfer

Beperkt zonetransfers. Standaard zijn zonetransfers toegestaan voor iedereen, maar dat is zeer zelden gewenst. In de voorbeeld named.conf is dit dan ook beperkt.

allow-query

Beperkt queries. Hiermee is in te stellen wie queries mag doen op de server of een zone. Als ns.example.com een slave zou zijn van office.example.com, dan zouden queries bijvoorbeeld beperkt kunnen worden tot het netwerk van example.com.

allow-recursion

Een recursieve query is een query voor een record waarvoor de server niet authoritative is. De server moet dus contact opnemen met andere nameservers om het antwoord te vinden. Dit levert een belasting op op de server die niet altijd gewenst is. In de voorbeeld named.conf is recursie beperkt tot het lokale netwerk.

allow-update

Zie DHCP: allow-update staat dynamische updates toe.

Elk van deze blokken kan een address match list bevatten of de naam van een access control list. Sommigen kunnen ook een key bevatten, voor TSIG-ondertekende aanvragen. Dit is met name nuttig bij zonetransfers en dynamic updates.

Address match lists

Een address match list bestaat uit een lijst met IP-adressen of IP-ranges gescheiden door puntkomma's. Een voorbeeld van een address match list is: 10/8; 172.16/12; 192.168/16;.

Access control lists

Een access control list (ACL) is een naam voor een address match list. Overal waar je een address match list kunt gebruiken, kunt je ook de naam van een ACL gebruiken. Hierdoor is named.conf korter, leesbaarder en beter onderhoudbaar te maken.

Overigens kan een address match list ook weer de naam van een ACL bevatten.

Een ACL wordt gedefinieerd met: acl "naam" { address match list; };". Een voorbeeld hiervan hebben we al gezien:

acl "local_net" {

localhost;

10/8;


172.16/12;

192.168/16;

};

Er zijn vier voorgedefinieerde ACLs:



none

De lege ACL

any

Alle mogelijke IP-adressen



localhost

Alle IP adressen van de machine waarop bind draait.

localnets

Alle subnetten waarop de machine waarop bind draait aangesloten is.

De laatste twee ACLs worden automatisch samengesteld aan de hand van de adressen van de netwerkinterfaces van de server op het moment van opstarten.

11.2 Views



Er zijn situaties waarin access control niet meer genoeg is. Bijvoorbeeld wanneer er binnen één zone zowel publieke- als privé-adressen gebruikt worden. In dat geval kun je views gebruiken.

Een voorbeeld van views, gedefinieerd in named.conf:

view "intern" {

match-clients {

local_net;

};

recursion yes;



zone "example.com" {

type master;

file "db.example.com.internal";

};

};



view "extern" {

match-clients {

any;

};

recursion no;



zone "example.com" {

type master;

file "db.example.com.external";

};

};



De naam van een view is puur informatief: bind doet er niets mee. Met match-clients selecteer je voor welke clients de view geldig is. Bind selecteert altijd de eerste view die voldoet.

In het eerste voorbeeld van named.conf wordt recursie beperkt door middel van allow-recursion, hier zie je hoe dat ook met views kan.

Beide views zien het domein example.com, maar de data komt uit verschillende zonefiles. Het kan soms handig zijn om een bestand db.example.com.common te maken met daarin de RR's die gedeeld worden tussen alle views. Met $INCLUDE db.example.com.common is dit bestand weer in te voegen in de beide zonefiles.

12. Beveiliging met chroot



Standaard draait bind als root en kan hij het hele bestandssysteem benaderen. Dat is niet zo veilig en ook onnodig. Er zijn twee maatregelen om bind veiliger te laten draaien:

• Draaien als unpriviliged user

• Draaien in een chroot

Normaal gebruik ik beide methoden: het is nauwelijks moeilijker en geeft net een beetje meer veiligheid.

12.1 Draaien in een chroot

Een chroot is een omgeving waarin een proces kan draaien in een eigen rootdirectory. In principe is het niet mogelijk (of heel moeilijk) om eruit te breken en in de echte root terecht te komen.

Als root voor bind gebruik ik /var/named/. Binnen deze directory moeten de volgende directory's aangemaakt worden:

• etc/ voor named.conf en eventuele keyfiles

• var/run/ voor named.pid

• zones/ voor master-zones

• zones/slave/ voor slave-zones

In het options blok in named.conf is één aanpassing nodig: "directory "/var/named/zones";" moet worden: "directory "/zones";".

Zorg dat alle directory's en bestanden lees- en schrijfbaar zijn voor het account waaronder bind draait, met name /var/named/var/run/ en /var/named/zones/.

Bind is nu te starten met:

named -t /var/named -c /etc/named.conf

named.conf wordt pas na de chroot ingelezen, vandaar dat de naam wordt opgegeven relatief ten opzichte van de nieuwe root. Het opgeven van plaats van named.conf is alleen nodig als bind deze probeert te lezen vanaf een non-standaard locatie, zoals in Debian.

12.2 Draaien als non-root



Veel distributies hebben standaard al een user named of bind aangemaakt. Die kunnen we gebruiken. Zo niet, maak dan zelf een user aan. Deze moet in een aparte groep komen waarin verder geen andere gebruikers rechten hebben.

Zorg ervoor dat bind kan schrijven in de directory waar named.pid terecht komt en in /var/named/zones. Bind is nu te starten met:

named -u named

Of, chrooted en als non-root:

named -t /var/named -c /etc/named.conf -u named

13. Resource Records

In deze appendix bespreek ik kort de belangrijkste Resource Records

13.1 SOA


Het SOA-record geeft aan welke nameserver autoriteit heeft over een zone en bevat informatie die voornamelijk voor slaveservers van belang is.

Een SOA-record ziet er als volgt uit:

SOA (









)

De velden hebben de volgende betekenissen:

nameserver

De naam van de master server

email

Het e-mailadres van de beheerder, met de apenstaart vervangen door een punt



serial

Dit is het serienummer van de zonefile. Wanneer het serienummer verhoogd wordt, zal de master de zonefile opnieuw inlezen na een reload, en de slaves zullen een zonetransfer doen

refresh

Dit is het tijdsinterval waarin een slaveserver bij de master controleert of het serienummer verhoogd is.



retry

Als de masterserver onbereikbaar was bij de laatste controle van het serienummer, dan gaat de slave opnieuw proberen na dit tijdsinterval

expire

Als de masterserver zo lang down is geweest als aangegeven in expire, dan verwijdert de slave de zone



minimum

De betekenis van dit veld wordt nogal eens verschillend uitgelegd. In principe zou het de TTL van negatieve antwoorden moeten zijn, maar er zijn meer mogelijkheden. Als je dit veld een niet al te wilde waarde geeft, en je zorgt dat je niet afhankelijk bent van die waarde, dan zit je altijd goed.

13.2 NS

Het NS-record bevat een delegatie voor een onderliggende zone naar een nameserver. Dit moet een naam zijn, geen IP-adres. Het is aan te raden om altijd minstens twee nameservers te hebben voor een zone.



13.3 A

Hierin wordt een IPv4-adres opgeslagen behorende bij een naam.

13.4 AAAA

Hierin wordt een IPv6-adres opgeslagen behorende bij een naam.

13.5 PTR

Hierin wordt een naam opgeslagen behorende bij een IPv4 (binnen in-addr.arpa) of IPv6-adres (binnen ip6.arpa of ip6.int).

13.6 MX

De data in een MX-record bestaat uit twee delen: een getal die de voorkeur (preference) aangeeft, en een naam van een mailserver. Sommige beheerders plaatsen een IP-adres in een MX-record, maar dat is domweg fout.



Een lagere preference betekent een hogere prioriteit. Mail voor het domein aangegeven in de naam van het RR gaat naar de mailservers aangegeven in de MX-records.

Een MX-record mag in principe niet wijzen naar een CNAME. Het is ten zeerste aan te raden om hem in elk geval naar een A-record te laten wijzen, ook als de betreffende server alleen via IPv6 bereikbaar is.

13.7 CNAME

Een CNAME is een alias voor een andere naam. Door het gebruik van CNAMEs kun je een server bereikbaar maken onder meerdere namen, zonder dat je zijn IP-adres meerdere malen hoeft op te slaan.

13.8 TXT

Dit resource record bevat vrije tekst. Zo kun je bijvoorbeeld opslaan waar een bepaalde computer staat.

13.9 A6

Misschien ooit de vervanger van het AAAA-record. Voorlopig nog niet in elk geval. Voor een beschrijving, zie het hoofdstuk over IPv6.



13.10 DNAME

Tegenhanger van het A6-record, maar dan voor reverses. Voor een beschrijving, zie het hoofdstuk over IPv6.

14. Tools

Om effectief een nameserver te kunnen onderhouden moet je ook kunnen omgaan met een aantal diagnostische tools. De belangrijkste twee zijn host en dig. Beide tools hebben ongeveer dezelfde functie: ze vragen resource records aan nameservers.

14.1 host

Host gebruik je vaak op de volgende manier:

host [-t type] name [server]

type: type resource record dat je wilt opvragen, standaard A

name: naam die je wilt opvragen

server: server waarbij je de RR gaat opvragen

Voorbeeld:

dexter:~ # host -t ns example.com

example.com. name server ns.example.com.

14.2 dig


Dig geeft gedetailleerdere uitvoer dan host. Ook heeft dig meer opties dan host. Zo kan dig bijvoorbeeld zone transfers doen.

Dig heeft een iets andere syntaxis dan host:

dig [@server] name [type]

Dig is vrij flexibel in de volgorde van de parameters, een aanroep als dig ns example.com @127.0.0.1 gaat ook goed.

Dig kan ook gebruik worden om zonetransfers te doen, handig om vanaf een slave even snel te testen of een master goed werkt:

dexter:~ # dig axfr example.com

; <<>> DiG 9.1.3 <<>> axfr example.com

;; global options: printcmd

example.com. 86400 IN SOA ns.example.com. erik.example.com. 2003040901 14400 7200 2419200 86400

example.com. 86400 IN NS ns.example.com.

example.com. 86400 IN MX 10 mail.example.com.

example.com. 86400 IN MX 100 mailbackup.provider.net.

example.com. 86400 IN A 10.0.0.1

ftp.example.com. 86400 IN CNAME www.example.com.

mail.example.com. 86400 IN A 10.0.0.3

ns.example.com. 86400 IN A 10.0.0.2

office.example.com. 86400 IN NS ns.office.example.com.

ns.office.example.com. 86400 IN A 10.0.1.1

www.example.com. 86400 IN A 10.0.0.1

example.com. 86400 IN SOA ns.example.com. erik.example.com. 2003040901 14400 7200 2419200 86400

;; Query time: 8 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Wed Apr 9 19:49:45 2003

;; XFR size: 13 records

Een zone transfer wordt bij conventie altijd afgesloten met een SOA-record, vandaar dat hij nu tweemaal voorkomt.

Veelvoorkomende opties van dig zijn:

-n gebruik nibble formaat om reverses van IPv6 adressen te vinden

-x vraag om een PTR-record voor het opgegeven IP-adres

+norec doet een niet-recursieve aanvraag zoals nameserers dat

onderling doen

14.3 nsupdate



TODO

15. Nameservers verhuizen

Soms is het nodig om nameservers te verhuizen, bijvoorbeeld als een domein moet verhuizen naar een andere provider. Dit kan grote problemen opleveren als het niet goed uitgevoerd wordt. Je loopt kans dat sommige providers een week na de verhuizing nog steeds de oude gegevens doorgeven.

15.1 De oorzaak

Oorzaak van het probleem is de dubbele opslag van NS records voor domeinen. NS records staan zowel in het bovenliggende domein (bijvoorbeeld 'net') als in het gedelegeerde domein ('hensema.net').

Bij een verhuizing zijn drie sets nameservers betrokken:

• De delegerende nameserver -- deze staan bij de registrar

• De oude gedelegeerde nameserver (de bron) -- deze staan bij de nieuwe provider

• De nieuwe gedelegeerde nameserver (het doel van de verhuizing) -- deze staan bij de nieuwe provider

Van deze drie sets servers geven twee de juiste informatie: de gedelegerende server en de nieuwe gedelegeerde servers. Twee sets servers geven informatie die volgens hen authoritative is: de beide gedelegeerde sets servers.

Vervuilde caches

Nameservers die recursieve queries doen naar het te verhuizen domein zullen vaak nog de oude NS records -- die dus wijzen naar de oude gedelegeerde nameservers -- nog in hun caches hebben staan. Verzoeken voor records in het domein zullen dan dus naar de oude nameservers gaan. Tot zover geen probleem.

Echter, normaal geeft een nameserver niet alleen het opgevraagde record, maar ook de NS records die geldig zijn voor het domein. Normaal worden deze extra records gebruikt om de non-authoritative records van de delegerende server te vervangen door authoritative records van de gedelegeerde server. Ze dienen echter genegeerd te worden als er al NS records in de cache stonden.

En hier zit het hele probleem. Sommige servers vervangen de records in hun cache door de records uit de extra informatie. Hiermee 'vervuilen' ze hun eigen cache met verkeerde data.

15.2 De oplossing

De oplossing is vrij simpel: zorg ervoor dat de oude gedelegeerde nameservers de nieuwe NS records kennen. Ze zullen dan voor elk verzoek niet de oude gegevens meesturen, maar juist de nieuwe. Op die manier vervuil je caches met de nieuwe -- juiste -- gegevens, en zal de verhuizing verlopen als gepland.

Wat je ook kunt doen: zet de TTL op de NS records veel lager dan de TTL op de rest van de records. Bijvoorbeeld 300 sec TTL op NS records en 1 dag TTL op de rest. NS records zullen dan sneller uit de cache verdwijnen dan de rest van de records. Daardoor worden recursieve servers gedwongen op de NS records opnieuw op te vragen van de delegerende server, die de juiste informatie geeft.

Iets wat ook effectief is: laat de zones verwijderen vanaf de oude servers. Ze hebben er immers niets meer te zoeken. Een server die geen informatie teruggeeft is stukken beter dan een server die foute informatie teruggeeft.

De allerlaatste oplossing is: wachten. Lang wachten. Ik heb servers na anderhalve week nog steeds de oude records zien geven.

16. Meer informatie

Hier komen links naar meer informatie

• DNS & Bind van O'Reilly

• Bv9ARM.pdf

• ISC.org



• http://www.bieringer.de/linux/IPv6/index.html

  • 2. Wat is DNS nou eigenlijk
  • 4.2 Configuratie van de werkstations
  • 5. Authoritative nameserver
  • 5.2 Over Resource Records
  • Ik loop stap voor stap door de zonefile heen: $TTL 1D
  • IN MX 10 mail.example.com.
  • 5.3 Configuratie in named.conf
  • 5.4 Over naamgeving van interne zones en domeinen
  • 6.1 Delegaties op interne netwerken

  • Dovnload 130.41 Kb.