Bedeutung der Stauts-Codes
Bei DNS-Anfragen können u. a. folgende Status-Codes zurückgemeldet werden:
SERVFAIL
Bedeutung: Die Antwort auf die Anfrage ist nicht bekannt. Unterbrechung zum zuständigen DNS Server. Ein Mailserver wird versuchen die Mail erneut abzusetzen.
NXDOMAIN
Bedeutung: Die Antwort auf die Anfrage ist bekannt. Sie lautet, die Domäne existiert nicht. Ein Mailserver wird eine Fehlermeldung an den Absender senden.
Zonetransfer manuell anstarten
auf DNS-Master-Servern wurde eine Änderung vorgenommen auf einem Slave-Server ist diese Änderung noch nicht sichtbar
auf dem Slave-Server ausführen:
rndc retransfer <zone>
also z. B.
rndc retransfer example.com
Zonetransfer testen
Um zu testen, ob ein Zonetransfer funktioniert, eignet sich z. B.
dig @<nameserver> -t AXFR <domain>
also z. B.
dig @127.0.0.1 -t AXFR example.com
Zu beachten ist, dass das normalerweise nur funktioniert, wenn man eine Quell-IP-Adresse hat, die für einen Zonetransfer auch zugelassen ist. Normalerweise also nur die Slave Nameserver.
Views konfigurieren (bind)
Ein DNS-Server (bind) bedient mehrere Client-Gruppen, z. B. Clients im Internet und Clients im Intranet. Interne Namen sollen aber von aussen nicht abfragbar sein. Dies kann über Views konfiguriert werden. Im u. g. Beispiel bekommen die Clients aus "special-net" die im View "special-net" definierten Zonen zu sehen und sonst nichts. Alle anderen erhalten den View "general".
Tipp: Es muss nicht unbedingt einen View "general" geben, dann erhalten die Clients die keinen View haben auch gar keine Namensauflösung. Will man nur einzelne Clients daran hindern, DNS-Queries abzusetzen, dann ist blackhole aber einfacher.
acl nodns {
10.10.10.10;
};
acl special-net {
10.10.11.0/24;
10.12.11.0/24;
};
options {
directory "/var/named/db/master/";
pid-file "named.pid";
version "secret";
check-names master ignore;
auth-nxdomain no;
allow-transfer { slaves; };
blackhole { nodns; };
transfer-format one-answer;
transfers-per-ns 5;
transfers-out 20;
also-notify {
10.11.11.11;
};
forward only;
forwarders {
212.212.212.212;
};
};
logging {
channel "logall" {
syslog local5;
};
category "default" {
"logall";
};
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "abcdedf";
};
view "special-net" {
match-clients { special-net; };
zone "example.com" {
type master;
file "special/db.example.com";
};
zone "beispiel.de" {
type master;
file "special/db.beispiel.de";
};
zone "10.in-addr.arpa" {
type master;
file "db.10";
};
};
view "general" {
match-clients { any; };
zone "beispiel.de" {
type master;
file "general/db.beispiel.de";
also-notify {
10.11.12.13;
10.11.12.14;
};
};
zone "10.in-addr.arpa" {
type master;
file "db.10";
also-notify {
10.11.12.13;
10.11.12.14;
};
};
};
Es ist auch möglich, je nach Client-IP für ein und den selben Namen, unterschiedliche IPs auszuliefern. Man muss nur über Views dafür sorgen, dass unterschiedliche Zone-Files gezogen werden. Unterscheiden sich die Zonen nur teilweise, dann schreibt man die gemeinsamen Einträge in eine dritte Datei und inkludiert diese in die beiden ersten.
$TTL 3D
@ IN SOA dns.beispiel.de root.localhost. (
1 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
NS dns.beispiel.de.
MX 10 mail.beispiel.de.
TXT "dns.beispiel.de"
dns A 192.168.18.3
mail A 192.168.18.1
majestix A 192.168.18.3
$INCLUDE /etc/bind/beispiel.de.common.zone
$TTL 3D
@ IN SOA dns.beispiel.de root.localhost. (
1 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
NS dns.beispiel.de.
MX 10 mail.beispiel.de.
TXT "dns.beispiel.de"
dns A 192.168.17.3
mail A 192.168.17.1
majestix A 192.168.17.3
$INCLUDE /etc/bind/beispiel.de.common.zone
$TTL 3D ; ; everything shared with all LAN zones ; proxy CNAME majestix time A 10.10.10.10 ntp A 10.10.10.10 smtp CNAME majestix pop3 CNAME majestix
DNSSEC
Obwohl DNS selbst für das Internet an und für sich von höchster Bedeutung ist, wird die gesamte Kommunikation dieses Protokolls im Klartext übertragen. Jeder unterwegs hat prinzipiell die Möglichkeit, die Kommunikation unbemerkt zu manipulieren. Dadurch wird unter anderem auch (z. B. staatlich verordnete) Zensur möglich.
Um mehr Vertrauen in die DNS-Infrastruktur zu bringen und die Möglichkeit zu schaffen, Manipulation zu bemerken, wurde DNSSEC entworfen.
Heiko Schlittermann hielt bei den Chemniter Linux-Tagen 2010 einen hervorragenden Vortrag zu DNSSEC in dem er die Grundlagen und Motivation erläuterte und auch auf die Umsetzung in der Praxis einging. In einem Workshop, den er zusammen mit Marcus Obst hielt, wurde der praktische Teil noch weiter vertieft.
Die Folien zum Vortrag und Workshop können als Grundlage für eigene Experimente dienen.