Berny's Knowledgebase als Newsfeed

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

Problem:

auf DNS-Master-Servern wurde eine Änderung vorgenommen auf einem Slave-Server ist diese Änderung noch nicht sichtbar

Lösung:

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.

beispiel.de.from.wlan.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.18.3
mail            A       192.168.18.1
majestix        A       192.168.18.3

$INCLUDE        /etc/bind/beispiel.de.common.zone
beispiel.de.from.eth.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
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.