FreeBSD gebruikt standaard een versie van BIND (Berkeley
Internet Name Domain), wat de meest gebruikte implementatie van
het DNS-protocol is. DNS
is het protocol waarmee namen aan IP-adressen
gebonden worden en vice versa. Zo wordt bijvoorbeeld op een
zoekopdracht voor www.FreeBSD.org
geantwoord met het
IP-adres van de webserver van het FreeBSD
Project en op een zoekopdracht voor ftp.FreeBSD.org
wordt geantwoord met het
IP-adres van de bijbehorende
FTP-machine. Het tegenovergestelde kan ook
gebeuren. Een zoekopdracht voor een IP-adres
kan de bijbehorende hostnaam opleveren. Het is niet nodig om
een naamserver te draaien om op een systeem zoekopdrachten met
DNS uit te voeren.
FreeBSD wordt momenteel standaard geleverd met de BIND9 DNS-serversoftware. Onze installatie biedt verbeterde beveilingsmogelijkheden, een nieuwe indeling van het bestandssysteem en geautomatiseerde configuratie van chroot(8).
DNS wordt op Internet onderhouden door een enigszins complex systeem van autoritaire root, Top Level Domain (TLD), en andere kleinschaligere naamservers die individuele domeininformatie hosten en cachen.
Op dit moment wordt BIND beheerd door het Internet Systems
Consortium https://www.isc.org/
.
Om dit document te begrijpen moeten een aantal termen gerelateerd aan DNS begrepen worden.
Term | Definitie |
---|---|
Voorwaartse DNS | Het afbeelden van hostnamen op IP-adressen. |
Herkomst (origin) | Verwijst naar het domein dat door een bepaald zonebestand wordt gedekt. |
named, BIND | Vaak gebruikte namen voor het naamserverpakket BIND in FreeBSD. |
Resolver | Een systeemproces waarmee een machine zoekopdrachten om zoneinformatie aan een naamserver geeft. |
Reverse DNS | Het afbeelden van IP-adressen op hostnamen. |
Rootzone | Het begin van de Internet zonehiërarchie. Alle zones vallen onder de rootzone, net zoals alle bestanden in een bestandssysteem onder de rootmap vallen. |
Zone | Een individueel domein, subdomein of een deel van de DNS die door dezelfde autoriteit wordt beheerd. |
Voorbeelden van zones:
.
is hoe de rootzone normaliter in de
documentatie genoemd wordt.
org.
is een Top Level Domain
(TLD) onder de rootzone.
example.org.
is een
zone onder het TLD
org.
.
1.168.192.in-addr.arpa
is een zone die
naar alle IP-adressen verwijst die onder
de IP-adresruimte 192.168.1.*
vallen.
Zoals te zien is staat het specifiekere deel van een
hostnaam aan de linkerkant. Zo is bijvoorbeeld example.org.
specifieker dan
org.
en is org.
specifieker dan de rootzone. De indeling van ieder deel van een
hostnaam lijkt veel op een bestandssysteem: de map
/dev
valt onder de root, enzovoort.
Naamservers bestaan in het algemeen in twee smaken: autoratieve naamservers en caching (ook bekend als resolving) naamservers.
Er is een autoratieve naamserver nodig als:
Het gewenst is om DNS-informatie aan te bieden aan de wereld om met autoriteit op verzoeken te antwoorden.
Een domein, zoals example.org
, is geregistreerd
en er IP-adressen aan hostnamen die
daaronder liggen toegewezen moeten worden.
Een IP-adresblok omgekeerde DNS-ingangen nodig heeft (IP naar hostnaam).
Een omgekeerde of tweede naamserver, die een slaaf wordt genoemd, moet antwoorden op verzoeken.
Er is een caching naamserver nodig als:
Een lokale DNS-server kan cachen en wellicht sneller kan antwoorden dan een naamserver die verder weg staat.
Als er een verzoek wordt gedaan voor www.FreeBSD.org
, dan doet de resolver
meestal een verzoek bij de naamserver van de
ISP die de uplink levert en ontvangt daarop
een antwoord. Met een lokale, caching
DNS-server hoeft het verzoek maar
één keer door de caching
DNS-server naar de buitenwereld gedaan te
worden. Voor aanvullende verzoeken hoeft niet buiten het lokale
netwerk te gaan omdat het al lokaal in de cache staat.
De daemon BIND heet in FreeBSD named.
Bestand | Beschrijving |
---|---|
named(8) | De daemon BIND. |
rndc(8) | Naamserverbeheerprogramma. |
/etc/namedb | Map waar zoneinformatie van BIND staat. |
/etc/namedb/named.conf | Instellingenbestand van de daemon. |
Afhankelijk van hoe en gegeven zone op de server is
geconfigureerd, staan de bestanden gerelateerd aan die zone in
de submappen master
,
slave
, of dynamic
van de map /etc/namedb
. Deze bestanden
bevatten de DNS-informatie die door de
naamserver als antwoord op zoekopdrachten gegeven zal worden.
Omdat BIND standaard wordt geïnstalleerd, is het instellen relatief eenvoudig.
De standaardconfiguratie van named is die van een eenvoudige resolverende naamserver, draaiende in een chroot(8)-omgeving, en beperkt tot het luisteren op het lokale IPv4-teruglusadres (127.0.0.1). Gebruik het volgende commando om de server eenmaal met deze configuratie te starten:
#
service named onestart
Om er zeker van te zijn dat de daemon
named elke keer bij het opstarten
gestart wordt, moet de volgende regel in
/etc/rc.conf
gezet worden:
named_enable="YES"
Het is duidelijk dat er vele instelopties voor
/etc/namedb/named.conf
zijn die buiten het
bereik van dit document vallen. Als u echter
geïnteresseerd bent in de opstartopties voor
named op FreeBSD, bekijk dan de
named_*
-vlaggen in
/etc/defaults/rc.conf
en raadpleeg de
handleidingpagina rc.conf(5). De sectie Paragraaf 12.7, “Gebruik van rc met FreeBSD” is ook nuttig om te lezen.
Instellingenbestanden voor named
bevinden zich momenteel in /etc/namedb
en moeten gewijzigd
worden voor gebruik, tenzij er alleen een eenvoudige resolver
nodig is. Hier vindt de meeste configuratie plaats.
// $FreeBSD$ // // In de handleidingpagina's named.conf(5) en named(8), en in de // documentatie in /usr/share/doc/bind9 zijn meer details te vinden. // // Voor het opzetten van een autoratieve server is een grondig begrip // van de werking van DNS noodzakelijk. Zelfs eenvoudige fouten kunnen // de werking verstoren voor beïnvloede partijen of veel onnodig // Internetverkeer veroorzaken. options { // Alle namen van bestanden en paden zijn relatief aan de chroot-map, // indien aanwezig, en moeten volledig gekwalificeerd zijn. directory "/etc/namedb/working"; pid-file "/var/run/named/pid" dump-file "/var/dump/named_dump.db" statistics-file "/var/stats/named.stats" // Als named alleen als een lokale resolver gebruikt wordt, is dit een // veilige standaardinstelling. Om named toegang tot het netwerk te // verschaffen, dient deze optie gecommentarieerd te worden, het // juiste IP-adres opgegeven te worden, of dient deze optie verwijderd // te worden. listen-on { 127.0.0.1; }; // Als u IPv6 aan heeft staan op dit systeem, dient deze optie // uitgecommentarieerd te worden om als lokale resolver te dienen. Om // toegang tot het netwerk te verschaffen, dient een IPv6-adres of het // sleutelwoord "any" gegeven te worden. // listen-on-v6 { ::1; }; // Deze zones zijn reeds opgenomen door de lege zones die hieronder // staan. Als u de gerelateerde lege zones hieronder verwijdert, // dienen deze regels uitgecommentarieerd te worden. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Als er een DNS-server beschikbaar is bij een upstream provider dan // kan het IP-adres op de regel hieronder ingegeven worden en kan die // geactiveerd worden. Hierdoor wordt voordeel gehaald uit de cache, // waardoor het algehele DNS-verkeer op het Internet vermindert. /* forwarders { 127.0.0.1; }; */ // Als de 'forwarders'-clausule niet leeg is, is de standaard om "forward // first" te gebruiken, welke terug zal vallen op het versturen van een // verzoek naar uw lokale server als de naamservers in 'forwarders' het // antwoord niet weten. Als alternatief kunt u uw naamserver dwingen om // nooit zelf verzoeken in te dienen door de volgende regel aan te // zetten: // forward only; // Als u forwarding automatisch wilt configureren gebaseerd op de regels // in /etc/resolv.conf, verwijder dan het commentaar van de volgende // regel en stel in /etc/rc.conf named_auto_forward=yes in. U kunt ook // named_auto_forward_only aanzetten (het effect hiervan is hierboven // beschreven). // include "/etc/namedb/auto_forward.conf";
Zoals al in het commentaar staat kan van een cache in de
uplink geprofiteerd worden als forwarders
ingeschakeld worden. Onder normale omstandigheden maakt een
naamserver recursief verzoeken tot het Internet op zoek naar
zekere naamservers tot er een antwoord komt waar het naar op
zoek is. Door de bovenstaande optie in te schakelen wordt
eerst de uplink naamserver (of de opgegeven naamserver)
gevraagd, waardoor er gebruik gemaakt kan worden van de cache
van die server. Als die uplink naamserver een drukke,
snelle naamserver is, kan het erg de moeite waard zijn om dit
aan te zetten.
127.0.0.1
werkt hier
niet. Verander dit
IP-adres in een naamserver in de
uplink.
/* Moderne versies van BIND gebruiken standaard een random UDP-poort voor elk uitgaand verzoek om de kans op cache poisoning drastisch te verminderen. Alle gebruikers wordt met klem verzocht om deze mogelijkheid te gebruiken en hun firewalls overeenkomstig aan te passen. ALS EEN LAATSTE UITVLUCHT om een beperkende firewall te omzeilen kunt u proberen om onderstaande optie aan te zetten. Het gebruik van deze optie vermindert uw kans om een cache poisoning aanval te weerstaan aanzienlijk, en dient indien mogelijk te worden vermeden. Vervang NNNNN in het voorbeeld door een getal tussen 49160 en 65530. */ // query-source address * port NNNNN; }; // Als er een lokale naamserver wordt gebruikt, vergeet dan niet om // eerst 127.0.0.1 in /etc/resolv.conf te zetten zodat die gevraagd // wordt. Controleer ook dat het in /etc/rc.conf is aangezet. // Het traditionele root-hint-mechanisme. Gebruik dit OF de // onderstaande slaafzones. zone "." { type hint; file "/etc/namedb/named.root"; }; /* Het slaaf maken van de volgende zones vanaf de root-naamservers heeft een aantal aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Geen vals verkeer dat vanaf uw netwerk naar de roots wordt verzonden 3. Betere weerstand tegen elke mogelijk falen van de rootserver/DDoS Wel is het zo dat deze methode meer toezicht vraagt dan het hintbestand om er zeker van te zijn dat een onverwachte faalmodus uw server niet heeft lamgelegd. Naamservers die veel clienten serveren zullen meer voordeel uit deze aanpak halen dan individuele hosts. Met zorg gebruiken. Verwijder het commentaar uit de onderstaande regels en commentarieer de bovenstaande hintzone om dit mechanisme te gebruiken. Zoals gedocumenteerd op http://dns.icann.org/services/axfr/ zijn deze zones: "." (de root), ARPA, IN-ADDR.ARPA, IP6.ARPA en ROOT-SERVERS.NET beschikbaar voor AXFR van deze servers op IPv4 en IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "/etc/namedb/slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; /* Het lokaal serveren van de volgende zones voorkomt dat enig verzoek voor deze zones uw netwerk verlaat en naar de root-naamservers gaat. Dit heeft twee aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Er zal geen vals verkeer vanaf uw netwerk naar de roots worden verzonden */ // RFCs 1912 en 5735 (en BCP32 voor localhost) zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // RFC 1912-stijl zone voor IPv6 localhost adres zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; // "Dit" netwerk (RFCs 1912 en 5735) zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Netwerken voor privaat gebruik (RFC 1918 en 5735) zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Lokale link/APIPA (RFCs 3927 en 5735) zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IETF protocol-toewijzingen (RFCs 5735 en 5736) zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // TEST-NET-[1-3] voor documentatie (RFCs 5735 en 5737) zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6-bereik voor documentatie (RFC 3849) zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Domeinnamen voor documentatie en testen (BCP 32) zone "test" { type master; file "/etc/namedb/master/empty.db"; }; zone "example" { type master; file "/etc/namedb/master/empty.db"; }; zone "invalid" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.com" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.net" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.org" { type master; file "/etc/namedb/master/empty.db"; }; // Router benchmarken (RFC 2544 en 5735) zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } // Gereserveerd door IANA - oude ruimte van klasse E (RFC 5735) zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; } // Niet-toegewezen IPv6-adressen (RFC 4291) zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } // IPv6 lokale link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } // IPv6 verouderde site-lokale adressen (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; } // IP6.INT is verouderd (RFC 4159) zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; } // NB: De IP-adressen hieronder zijn bedoeld als voorbeeld en dienen // niet gebruikt te worden! // // Voorbeeld instellingen voor slaafzones. Het kan handig zijn om // tenminste slaaf te worden voor de zone waar de host onderdeel van // uitmaakt. Bij uw netwerkbeheerder kan het IP-adres van de // verantwoordelijke meester-naamserver nagevraagd worden. // // Vergeet niet om de omgekeerde lookup-zone op te nemen! // Dit is genoemd na de eerste bytes van het IP-adres, in omgekeerde // volgorde, met daarachter ".IN-ADDR.ARPA", of "IP6.ARPA" voor IPv6. // // Het is van groot belang om de werking van DNS en BIND te begrijpen // voordat er een meester-zone wordt opgezet. Er zijn nogal wat // onverwachte valkuilen. Het opzetten van een slaafzone is // gewoonlijk eenvoudiger. // // NB: Zet de onderstaande voorbeelden niet blindelings aan. :-) // Gebruik in plaats hiervan echte namen en adressen. /* Een voorbeeld van een dynamische zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "/etc/namedb/dynamic/example.org"; }; */ /* Voorbeeld van een omgekeerde slaafzone zone "1.168.192.in-addr.arpa" { type slave; file "/etc/namedb/slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */
In named.conf
zijn dit voorbeelden
van slaafregels voor een voorwaartse en een omgekeerde
zone.
Voor iedere nieuwe zone die wordt aangeboden dient een
nieuwe instelling voor de zone aan
named.conf
toegevoegd te worden.
De eenvoudigste instelling voor de zone example.org
kan er als volgt
uitzien:
zone "example.org" { type master; file "master/example.org"; };
De zone is een master, zoals aangegeven door het statement
type
, waarvan de zoneinformatie in
/etc/namedb/example.org
staat, zoals het
statement file
aangeeft.
zone "example.org" { type slave; file "slave/example.org"; };
In het geval van de slaaf wordt de zoneinformatie voor een zone overgedragen van de master naamserver en opgeslagen in het ingestelde bestand. Als de masterserver het niet meer doet of niet bereikbaar is, dan heeft de slaveserver de overgedragen zoneinformatie nog en kan het die aanbieden.
Een voorbeeldbestand voor een masterzone voor example.org
(bestaande binnen
/etc/namedb/master/example.org
) ziet er
als volgt uit:
$TTL 3600 ; 1 uur standaard TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Verversen 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ; Negatieve antwoord-TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machinenamen localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mail IN A 192.168.1.4 mx IN A 192.168.1.5 ; Aliases www IN CNAME example.org.
Iedere hostnaam die eindigt op een “.” is
een exacte hostnaam, terwijl alles zonder een
“.” op het einde relatief is aan de oorsprong.
Zo wordt ns1
bijvoorbeeld vertaald naar
ns1.example.org.
.
De regels in een zonebestand volgen de volgende opmaak:
recordnaam IN recordtype waarde
De meest gebruikte DNS-records:
begin van autoriteit (start of authority)
een bevoegde (autoratieve) name server
een hostadres
de canonieke naam voor een alias
mail exchanger
een domeinnaam pointer (gebruikt in omgekeerde DNS)
example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs na 3 uur 3600 ; Opnieuw proberen na 1 uur 604800 ; Verlopen na 1 week 300 ; Negatieve antwoord-TTL
example.org.
de domeinnaam, ook de oorsprong voor dit zonebestand.
ns1.example.org.
de primaire/bevoegde naamserver voor deze zone.
admin.example.org.
de persoon die verantwoordelijk is voor
deze zone, emailadres met “@” vervangen.
<admin@example.org>
wordt
admin.example.org
.
2006051501
het serienummer van het bestand. Dit moet iedere
keer als het zonebestand wordt aangepast opgehoogd
worden. Tegenwoordig geven veel beheerders de voorkeur
aan de opmaak yyyymmddrr
voor het
serienummer. 2006051501
betekent
dan dat het voor het laatst is aangepast op
15–05–2006, de laatste
01
betekent dat het zonebestand die
dag voor het eerst is aangepast. Het serienummer is
belangrijk omdat het slaafnaamservers aangeeft dat een
zone is bijgewerkt.
IN NS ns1.example.org.
Hierboven staat een NS-regel. Voor iedere naamserver die bevoegde antwoorden moet geven voor de zone hoort er zo'n regel te zijn.
localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5
Een A-record geeft een machinenaam aan. Hierboven is te
zien dat ns1.example.org
zou
resolven naar 192.168.1.2
.
IN A 192.168.1.1
Deze regel kent IP-adres 192.168.1.1
toe aan de huidige
oorsprong, in dit geval example.org
.
www IN CNAME @
Een canoniek naamrecord wordt meestal gebruikt voor het
geven van aliassen aan een machine. In het voorbeeld is
www
een alias naar de “master”
machine waarvan de naam gelijk is aan de domeinnaam example.org
(192.168.1.1
). CNAME's kunnen
nooit samen met een ander soort record voor dezelfde hostnaam
gebruikt worden.
IN MX 10 mail.example.org.
MX records geven aan welke mailservers verantwoordelijk
zijn voor het afhandelen van inkomende mail voor de zone.
mail.example.org
is de hostnaam
van een mailserver en 10 is de prioriteit voor die mailserver.
Het is mogelijk meerdere mailservers in te stellen met
prioriteiten 10, 20, enzovoorts. Een mailserver die probeert
mail af te leveren voor example.org
probeert dat eerst
bij de MX met de hoogste prioriteit (het record met het
laagste prioriteitsnummer), daarna de tweede hoogste,
enzovoort, totdat de mail afgeleverd kan worden.
Voor in-addr.arpa zonebestanden (omgekeerd DNS) wordt dezelfde opmaak gebruikt, maar dan met PTR-regels in plaats van A of CNAME.
$TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ) ; Negatieve antwoord-TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org.
Dit bestand geeft de juiste IP-adressen voor hostnamen in het voorbeelddomein hierboven.
Het is het vernoemen waard dat alle namen aan de rechterkant van een PTR-record volledig gekwalificeerd dienen te zijn (i.e., met een “.” eindigen).
Een caching naamserver is een naamserver wiens primaire rol het oplossen van recursieve verzoeken is. Het dient simpelweg zelf verzoeken in en onthoudt de antwoorden voor later gebruik.
Domain Name Security System Extensions, ofwel DNSSEC, is een
verzameling van specificaties om resolvende naamservers te beschermen
tegen valse DNS-gegevens, zoals vervalste
DNS-records. Door digitale handtekeningen te
gebruiken kan een resolver de integriteit van een record controleren.
Merk op dat DNSSEC
alleen integriteit biedt via het digitaal ondertekenen van het Resource
Record (RRs). Het biedt noch
betrouwbaarheid noch bescherming tegen onjuiste aannames van
eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen
het bezoeken van example.net
in
plaats van example.com
. Het enige
wat DNSSEC doet is authenticeren dat de gegevens
niet tijdens het transport zijn gecompromitteerd. De beveiliging van
DNSSEC is een belangrijke stap in het beveiligen van
het internet in het algemeen. De relevante RFCs zijn
een goed beginpunt voor meer gedetailleerde gegevens over hoe
DNSSEC werkt. Raadpleeg de lijst in
Paragraaf 29.6.10, “Verder lezen”.
De volgende secties laten zien hoe DNSSEC voor een autoratieve DNS-server en een recursieve (of caching) DNS-server die BIND 9 draait kan worden bewerkstelligd. Hoewel alle versies van BIND 9 DNSSEC ondersteunen, is tenminste versie 9.6.2 nodig om gebruik te kunnen maken van de ondertekende rootzones tijdens het valideren van DNS-verzoeken. Dit komt doordat eerdere versies de benodigde algoritmes om validatie met de sleutel voor de rootzone te uit te voeren niet hebben. Het wordt sterk aangeraden om de nieuwste versie van BIND 9.7 te gebruiken om gebruik te kunnen maken van automatische sleutel-updates voor de rootsleutel en van andere mogelijkheden om zones ondertekend en sleutel up-to-date te houden. Wanneer configuraties tussen 9.6.2 en 9.7 en later verschillen, zullen deze worden toegelicht.
Het aanzetten van DNSSEC-validatie van
verzoeken die door een recursieve DNS-server worden
uitgevoerd heeft enkele aanpassingen aan
named.conf
nodig. Voordat deze wijzigingen
worden gemaakt dient de rootzone-sleutel, of vertrouwensanker, te
worden opgehaald. Momenteel is de rootzone-sleutel niet beschikbaar
in een bestandsformaat dat BIND begrijpt, dus moet
het handmatig in het juiste formaat omgezet worden. De sleutel zelf
kan verkregen worden door de rootzone ervoor met
dig te ondervragen. Door
%
dig +multi +noall +answer DNSKEY . > root.dnskey
te draaien, wordt de sleutel in root.dnskey
opgeslagen. De inhoud dient er ongeveer als volgt uit te zien:
. 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 93910 IN DNSKEY 256 3 8 ( AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525
Schrik niet als de verkregen sleutels anders zijn dan in dit voorbeeld. Ze kunnen zijn veranderd nadat deze instructies voor het laatst waren bijgewerkt. De uitvoer bevat in feite twee sleutels. De eerste sleutel, met de waarde 257 na het DNSKEY-recordtype, is degene die nodig is. Deze waarde geeft aan dat dit een Secure Entry Point ( SEP) is, beter bekend als een Key Signing Key (KSK). De tweede sleutel, met de waarde 256, is een deelsleutel, beter bekend als een Zone Signing Key (ZSK). Meer over de verschillende soorten sleutels komt aan bod in Paragraaf 29.6.8.2, “Configuratie van een autoratieve DNS-server”.
Nu moet de sleutel gecontroleerd en geformatteerd worden zodat BIND deze kan gebruiken. Maak om de sleutel te controleren een DS - RR-paar aan. Maak een bestand aan dat deze RRs bevat aan met
%
dnssec-dsfromkey -f root-dnskey . > root.ds
Deze records gebruiken respectievelijk SHA-1 en SHA-256, en dienen er als het volgende voorbeeld uit te zien, waarbij het langere record SHA-256 gebruikt.
. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
Het SHA-256 RR kan nu worden vergeleken met de digest in https://data.iana.org/root-anchors/root-anchors.xml. Om er absoluut zeker van te zijn dat er niet geknoeid is met de sleutel kunnen de gegevens in het XML-bestand worden gecontroleerd met de PGP-handtekening in https//data.iana.org/root-anchors/root-anchors.asc.
Vervolgens dient de sleutel juist geformateerd te worden. Dit
verschilt een beetje tussen versie 9.6.2 en versie 9.7 en later van
BIND. In versie 9.7 is ondersteuning toegevoegd om
automatisch veranderingen aan de sleutel te volgen en deze bij te
werken indien nodig. Dit wordt gedaan met
managed-keys
zoals in het volgende voorbeeld te
zien is. Als de oudere versie gebruikt wordt, wordt de sleutel
toegevoegd met een commando trusted-keys
en dient
deze handmatig bijgewerkt te worden. Voor BIND
9.6.2 ziet het formaat er uit als:
trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; };
Voor versie 9.7 ziet het formaat er echter zo uit:
managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; };
De rootsleutel kan nu aan named.conf
worden
toegevoegd, ofwel direct of door een bestand dat de sleutel bevat te
includen. Stel na deze stappen BIND in zodat het
DNSSEC-validatie uitvoert op verzoeken door
named.conf
te bewerken en het volgende aan de
directief options
toe te voegen:
dnssec-enable yes; dnssec-validation yes;
Om te controleren dat het ook echt werkt, kan
dig gebruikt worden om een verzoek op een
ondertekende zone uit te voeren met de zojuist geconfigureerde
resolver. Een succesvol antwoord zal de vlag AD
bevatten om aan te geven dat de gegevens zijn geautenticeerd. Een
verzoek als
%
dig @resolver +dnssec se ds
zou het DS RR paar voor de
.se
-zone moeten teruggeven. In de sectie
flags:
moet de vlag AD
te zien
zijn, als in:
... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ...
De resolver is nu in staat om DNS-verzoeken te autenticeren.
Om een autoratieve naamserver een met DNSSEC ondertekende zone te laten serveren is wat meer werk nodig. Een zone wordt ondertekend met cryptografische sleutels die aangemaakt moeten worden. Het is mogelijk om hier slechts één sleutel voor te gebruiken. De methode die de voorkeur verdient is echter om een sterke, goed beschermde Key Signing Key (KSK) die niet vaak wordt geroteerd en een Zone Signing Key (ZSK) die vaker wordt geroteerd te hebben. Informatie over aanbevolen procedures staat in RFC 4641: DNSSEC Operational Practices. Procedures betreffende de rootzone staan in DNSSEC Practice Statement for the Root Zone KSK operator en DNSSEC Practice Statement for the Root Zone ZSK operator. De KSK wordt gebruikt om een autoriteitsketen voor de te valideren gegevens op te bouwen en wordt daarom ook een Secure Entry Point (SEP)-sleutel genoemd. Een bericht-digest van deze sleutel, dat Delegation Signer (DS)-record genoemd wordt, moet gepubliceerd zijn in de ouderzone om een vertrouwensketen op te bouwen. Hoe dit bereikt wordt hangt af van de eigenaar van de ouderzone. De ZSK wordt gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd te worden.
Om DNSSEC aan te zetten voor de zone example.com
zoals beschreven in de
voorgaande voorbeelden, dient als eerste
dnssec-keygen gebruikt te worden om het
sleutelpaar met de KSK en ZSK
te genereren. Dit sleutelpaar kan verschillende cryptografische
algoritmes gebruiken. Het wordt aanbevolen om RSA/SHA-256 voor de
sleutels te gebruiken, een sleutellengte van 2048 bits zou voldoende
moeten zijn. Om de KSK voor example.com
te genereren:
%
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com
en om de ZSK te genereren:
%
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
dnssec-keygen maakt twee bestanden, de
publieke en private sleutels in bestanden met namen als
Kexample.com.+005+nnnnn.key
(publiek) en
Kexample.com.+005+nnnnn.private
(privaat). Het
gedeelte nnnnn
van de bestandsnaam is een
sleutel-ID van vijf cijfers. Houd bij welke sleutel-ID bij welke
sleutel hoort. Dit is in het bijzonder van belang wanneer er meerdere
sleutels per zone zijn. Het is ook mogelijk om de sleutels te
hernoemen. Voor elk KSK-bestand:
%
mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnn.KSK.key
%
mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private
Voor ZSK-bestanden dient KSK
waar nodig door ZSK
vervangen te worden. De
bestanden kunnen nu worden opgenomen in het zonebestand, door de
opdracht $include
te gebruiken. Het zou er
ongeveer als volgt uit moeten zien:
$include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK
Onderteken tenslotte de zone en vertel BIND om
het ondertekende zonebestand te gebruiken. Voor het ondertekenen van
een zone wordt dnssec-signzone gebruikt.
Het commando om de zone example.com
, dat zich in
example.com.db
bevindt, zou er ongeveer zo
uit moeten zien:
%
dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key
De sleutel die aan het argument -k
wordt
meegegeven is de KSK en het andere sleutelbestand
is de ZSK dat bij het ondertekenen gebruikt moet
worden. Het is mogelijk om meer dan één
KSK en ZSK op te geven, wat tot
gevolg heeft dat de zone met alle meegegeven sleutels wordt
ondertekend. Dit kan nodig zijn om zonegegevens aan te leveren die
met meerdere algoritmes zijn ondertekend. De uitvoer van
dnssec-signzone is een zonebestand met
daarin alle RRs ondertekend. Deze uitvoer komt in
een bestand met de extensie .signed
terecht, zoals
example.com.db.signed
. De DS-records worden ook naar een
apart bestand dsset-example.com
geschreven. Om
deze ondertekende zone te gebruiken hoeft alleen de zone-directief in
named.conf
veranderd te worden om
example.com.db.signed
. Standaard zijn de
ondertekeningen slechts 30 dagen geldig, wat betekent dat de zone over
ongeveer 15 dagen hertekend moet worden om er zeker van te zijn dat
resolvers geen records met oude ondertekeningen cachen. Het is
mogelijk om hiervoor een script en een crontaak te maken. Bekijk de
relevante handleidingen voor details.
Zorg ervoor dat de private sleutels veilig blijven, zoals met alle cryptografische sleutels. Bij het veranderen van een sleutel kan het beste de nieuwe sleutel in de zone opgenomen worden, en nog met de oude sleutel te ondertekenen, en om daarna over te stappen op de nieuwe sleutel. Nadat deze handelingen zijn voltooid kan de oude sleutel uit de zone worden verwijderd. Wanneer dit niet wordt gedaan kunnen de DNS-gegevens tijdelijk onbeschikbaar zijn totdat de nieuwe sleutel door de DNS-hiërarchie is gepropageerd. Meer informatie over sleutelwisselingen en andere praktijken rondom DNSSEC staan in RFC 4641: DNSSEC Operational practices.
In versie 9.7 van BIND is een nieuwe
mogelijkheid genaamd Smart Signing
geïntroduceerd. Deze mogelijkheid heeft als doel om het
sleutelbeheer en ondertekenproces eenvoudiger te maken door delen van
deze taken te automatiseren. Door de sleutels in een
sleutelreservoir te stoppen en de nieuwe optie
auto-dnssec
te gebruiken, is het mogelijk om een
dynamische zone aan te maken welke opnieuw getekend wordt indien dat
nodig is. Gebruik om deze zone bij te werken
nsupdate met de nieuwe -l
.
rndc kan nu ook zones ondertekenen met
sleutels uit het sleutelreservoir door de optie sign
te gebruiken. Voeg, om BIND dit automatische
ondertekenen en bijwerken van zones te laten gebruiken voor example.com
, het volgende aan
named.conf
toe:
zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; auto-dnssec maintain; file "/etc/named/dynamic/example.com.zone"; };
Nadat deze veranderingen gemaakt zijn, dienen de sleutels voor de
zone aangemaakt te worden zoals uitgelegd in Paragraaf 29.6.8.2, “Configuratie van een autoratieve
DNS-server”, deze sleutels in het sleutelreservoir
gestopt te worden dat als argument aan de
key-directory
in het zoneconfiguratie is
meegegeven, waarna de zone automatisch zal worden ondertekend. Zones
die op deze manier zijn geconfigureerd dienen met
nsupdate te worden gedaan, dat voor het
opnieuw ondertekenen van de zone met de nieuw toegevoegde gegevens zal
zorgen. Zie voor meer details Paragraaf 29.6.10, “Verder lezen” en de
BIND-documentatie.
Hoewel BIND de meest gebruikte implementatie van DNS is, is er altijd nog het beveiligingsvraagstuk. Soms worden er mogelijke en te misbruiken beveiligingsgaten gevonden.
Hoewel FreeBSD named automatisch in een chroot(8)-omgeving plaatst; zijn er verschillende andere beveiligingsmechanismen actief die zouden kunnen helpen om mogelijke aanvallen op de DNS-dienst af te wenden.
Het is altijd verstandig om de CERT beveiligingswaarschuwingen te lezen en een abonnement te nemen op de FreeBSD beveiligingswaarschuwingen mailinglijst om bij te blijven met de beveiligingsproblemen wat betreft Internet en FreeBSD.
Als er problemen ontstaan, kan het bijwerken van broncode en het opnieuw bouwen van named hulp bieden.