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.
Om bind te laten luisteren op IPv6 kun je het volgende toevoegen aan
het options-blok in named.conf:
listen-on-v6 {
any;
};
any door een lijst van IPv6-adressen waaronder
de server bereikbaar moet zijn.
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
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:
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.
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";
};
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.
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.
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.
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 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:
A6-record.A6-record dat de
rest van het adres bevatA6 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.
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.
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::
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.
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.
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 <adres>" zal dus
falen. Voeg de optie -n toe om het 'oude' (lees: huidige)
nibble-formaat te gebruiken: dig -n -x <adres>.
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.