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.
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:
www.example.com, dat valt binnen het domein
example.comwww.sales.example.com, dat valt binnen het
domein sales.example.comoffice.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.
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:
Koppelt een IPv4-adres aan een naam
Koppelt een IPv6-adres aan een naam
Koppelt een naam aan een IPv4-adres, zie Reverse Lookups
Koppelt een naam aan een andere naam (alias)
Delegeert een zone naar een andere nameserver
Definieert een zogenaamde Mail eXchanger
Definieert een Start Of Authority; geeft aan wie autoriteit heeft over een bepaalde zone
De appendix over resource records bespreekt deze in meer detail.
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.
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 <nameserver> <email> (
<serial>
<refresh>
<retry>
<expire>
<minimum> )
<nameserver> 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.
<serial> 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.
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";
};
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:
killall
-HUP namedrndc reload.Die laatste methode heeft wel wat extra configuratie nodig, waar ik hier niet op zal ingaan.
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.
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 <nummer> 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
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
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.