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 */
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.
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.