Ralf Zimmermann SIEGNETZ.IT GmbH

Möchte man nicht auf kostenpflichtige Dienste wie DynDNS zurückgreifen, kann man auch sehr einfach dynamische Records mit nsupdate aktualisieren und setzen. Dafür benötigt man z.B. einen TSIG Key den man folgendermassen erzeugen kann.

Note:Ich möchte hier nur kurz zeigen wie es geht. Wer das in einer produktiven Umgebung einsetzen möchte, der sollte sich die entsprechenden Kapitel in der Bind Dokumentation durchlesen.

TSIG Key erzeugen

# dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST rz.siegnetz.de

Der Befehl erzeugt zwei Dateien.

-rw------- 1 root root 123 Oct 26 10:30 Krz.siegnetz.de.+157+01635.key
-rw------- 1 root root 229 Oct 26 10:30 Krz.siegnetz.de.+157+01635.private

Key der named.conf hinzufügen und Zone anpassen

Den Key aus der Datei Krz.siegnetz.de.+157+01635.key der named.conf hinzufügen.

key "rz.siegnetz.de." {
  algorithm hmac-md5;
  secret "DPffvzjShGiVGd8KC/0rqb24yPsHr4e9Pw/zyrMDTj7JxfgkUBpbKFea zI8yYabwlIdR8MlDZRu/9AFo+yckxw==";
};

Nun muss die Konfiguration der Zone noch angepasst werden.

zone "domain.de" in {
        type master;
        file "dynamic/domain.de/domain.de";
        allow-transfer { none; };
        notify yes;
        update-policy {
                grant local-ddns zonesub ANY;
                grant rz.siegnetz.de. name rzimmermann.domain.de. A AAAA TXT;
        };
        forwarders {};
        zone-statistics yes;
        key-directory "dynamic/domain.de";
        auto-dnssec maintain;
        inline-signing yes;
        sig-validity-interval 30;
}

nsupdate

Nun kann man mittels nsupdate die Records in der Zone z.B. hinzufügen oder updaten.

# nsupdate -k Krz.siegnetz.de.+157+01635.private
server master.domain.de
debug yes
zone domain.de.
update add rzimmermann.domain.de. 86400 A 185.15.194.87
update add rzimmermann.domain.de. 86400 AAAA 2a03:2a00:1300:0:5700::10
show
send

Mittels eines einfachen Scripts lässt sich das Updaten des Records automatisieren. Hier ein Beispiel mit einem Bash Script.

#!/bin/bash
# 
# DNS Update Script für Host rzimmermann.domain.de

IPV4=$(curl -s "http://checkip.siegnetz.de")

KEY=./Krz.siegnetz.de.+157+01635.private
NS="master.domain.de"
DOMAIN="rzimmermann.domain.de."
ZONE="domain.de."

nsupdate -k $KEY -v << EOF
server $NS
zone $ZONE
update delete $DOMAIN A
update add $DOMAIN 600 A $IPV4
show
send
EOF

DNSSEC aktivieren

managed-keys {
    # ISC DLV: See https://www.isc.org/solutions/dlv for details.
    # NOTE: This key is activated by setting "dnssec-lookaside auto;"
    # in named.conf.
    dlv.isc.org. initial-key 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
    brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
    1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
    ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
    Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
    QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
    TDN0YUuWrBNh";

    # ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
    # for current trust anchor information.
    # NOTE: This key is activated by setting "dnssec-validation auto;"
    # in named.conf.
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

options {
  /* DNSSEC configuration */
  dnssec-enable yes; // All BIND 9 versions
  dnssec-validation yes; // BIND 9.4.3-P2 and later
  /* Tell BIND 9 to use DLV, in addition to normal DNSSEC validation */
  dnssec-lookaside . trust-anchor dlv.isc.org.;
};

dig zum verifizieren von DNSSEC verwenden

Auf folgende drei Punkte ist zu achten, wenn man DNSSEC DNS Records mittels dig überprüft.

1. Das Authenticated Data (ad) flag muss gesetzt sein
2. Das DNSSEC OK (do) flag gibt an, dass der recursive Server DNSSEC verwendet
3. In dem Abfrageergebnis sollte ein Resource Record vom Type RRSIG auftauchen, der zum A oder AAAA Record passt

Das DNSSEC OK (do) flag zeigt an, dass der recursive Nameserver DNSSEC verwendet. Das Authenticated Data (ad) flag ist gesetzt, wenn die Antwort erfolgreich den DNSSEC Validierungsprozess durchlaufen hat.

$ dig rz.siegnetz.de. +dnssec +multiline 

; <<>> DiG 9.10.1-P1 <<>> rz.siegnetz.de. +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1142
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rz.siegnetz.de.		IN A

;; ANSWER SECTION:
rz.siegnetz.de.		3553 IN	A 185.15.194.87
rz.siegnetz.de.		3553 IN	RRSIG A 5 3 3600 (
                20150130123458 20141231120808 44805 siegnetz.de.
                meeH5+MfBnbQ0YuOlFuAQG7hsC/0GKYT11g01WBfBafH
                vs6Zqg6Bi62nV5bpgk3VmnUaBltpvyGTiI8FQ/SziZje
                GJKv7vCZ90OyJISb0+6Pi62UMWoHXbbR7NhwYqaM1fwp
                A6ahCRJj9n4ZlA2a6FqUHzjjSrQBJnWyzo2KXpE= )

delv zum verifizieren verwenden

Ab Bind 9.10 kann man das Tool Domain Entity Lookup & Validation (delv) zum validieren von DNSSEC verwenden. Das Tool ähnelt dig, ist aber speziell für DNSSEC Abfragen zu verwenden.

$ delv rz.siegnetz.de. +multiline +rtrace
;; fetch: rz.siegnetz.de/A
;; fetch: siegnetz.de/DNSKEY
;; fetch: siegnetz.de/DS
;; fetch: de/DNSKEY
;; fetch: de/DS
;; fetch: ./DNSKEY
;; fetch: siegnetz.de.dlv.isc.org/DLV
;; fetch: dlv.isc.org/DNSKEY
; fully validated
rz.siegnetz.de.		3453 IN	A 185.15.194.87
rz.siegnetz.de.		3453 IN	RRSIG A 5 3 3600 (
                20150130123458 20141231120808 44805 siegnetz.de.
                meeH5+MfBnbQ0YuOlFuAQG7hsC/0GKYT11g01WBfBafH
                vs6Zqg6Bi62nV5bpgk3VmnUaBltpvyGTiI8FQ/SziZje
                GJKv7vCZ90OyJISb0+6Pi62UMWoHXbbR7NhwYqaM1fwp
                A6ahCRJj9n4ZlA2a6FqUHzjjSrQBJnWyzo2KXpE= )

DNSSEC Validierungsproblem feststellen

Was ist, wenn alle DNSSEC Abfragen mit einer SERVFAIL Fehlermeldung beantwortet werden? Wie kann man feststellen, ob das Problem mit DNSSEC zu tun hat?

Dig besitzt die Möglichkeit die DNSSEC Validierung mittels des Flag +cd (checking disable) abzuschalten. Erhält man bei einer DNSSEC Abfrage eine SERVFAIL Meldung, dann führt man die Abfrage nochmal aber mit +cd Flag aus. Wird diese Abfrage ohne eine SERVFAIL Meldung beantwortet, dann handelt es sich um ein DNSSEC Validierungsproblem.

$ dig rz.siegnetz.de. +multiline +cd 

; <<>> DiG 9.10.1-P1 <<>> rz.siegnetz.de. +multiline +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62415
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rz.siegnetz.de.		IN A

;; ANSWER SECTION:
rz.siegnetz.de.		3353 IN	A 185.15.194.87

;; AUTHORITY SECTION:
siegnetz.de.		65725 IN NS ns.siegnetz.de.
siegnetz.de.		65725 IN NS dns1.epag.net.
siegnetz.de.		65725 IN NS dns2.epag.net.

;; ADDITIONAL SECTION:
ns.siegnetz.de.		85356 IN A 89.146.217.138
ns.siegnetz.de.		85356 IN AAAA 2a01:130:2000:123::103
dns1.epag.net.		152125 IN A 212.123.35.78
dns1.epag.net.		152125 IN A 217.76.102.142
dns2.epag.net.		152125 IN A 212.123.32.78

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 06 17:55:55 CET 2015
;; MSG SIZE  rcvd: 214

How To Use

Es kommt bei DNSSEC Konfigurationen oft zu Problemen bei denen DNS resolver grosse Antwortpakete erhalten. Oft entsteht dieses Problem auch bei der Verwendung von Firewalls die auf Application Level Ebene die DNS Pakete prüfen. Dies kann z.B. längere Antwortzeiten verursachen. Können keine DNSSEC Anfragen per UDP erfolgreich aufgelöst werden, kommt es zu einem Fallback über TCP.

Die maximale reply size zwischen einem DNS Server und einem resolver kann von mehreren Faktoren abhängen.

• Unterstützt ein resolver nicht Extension Mechanisms for DNS (EDNS), dann sind Antwortpakete auf 512 bytes beschränkt
• Der resolver wird hinter einer Firewall betrieben, die IP Fragmente blockt.
• Firewalls mit DNS ALG's blocken Pakete die größer als 512 bytes sind.

$ dig +short rs.dns-oarc.net txt
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 4023 bytes"

No EDNS

Die folgende Antwort kommt von einem DSL Router der EDNS nicht unterstützt:

rst.x486.rs.dns-oarc.net.
rst.x454.x486.rs.dns-oarc.net.
rst.x384.x454.x486.rs.dns-oarc.net.
"X.X.X.X DNS reply size limit is at least 486 bytes"
"X.X.X.X lacks EDNS, defaults to 512"

IP Fragments Filtered

Wird ein resolver hinter einer Firewall betrieben die IP Fragmente filtert, dann wird man Pakete mit einer Größe kleiner 1400 bytes erhalten:

rst.x1014.rs.dns-oarc.net.
rst.x1202.x1014.rs.dns-oarc.net.
rst.x1382.x1202.x1014.rs.dns-oarc.net.
"X.X.X.X sent EDNS buffer size 4096"
"X.X.X.X DNS reply size limit is at least 1382 bytes"

Inconsistent Results

Werden DNS Pakete geblockt oder verändert kann es zu inkonsistenten Ergebnissen kommen. Die Antwortpakete haben eine TTL von 60 Sekunden. Daher sollte man einen weiteren Test erst nach 60 Sekunden durchführen.

Truncated, retrying in TCP mode

Manche resolver senden die komplette authority section zurück. Dig setzt den EDNS receive buffer nicht standardmässig, sodass nicht die komplette Antwort empfangen wird. Um dieses Problem zu umgehen kann man dig eine grössere receive buffer Größe angeben:

$ dig +bufsize=1024 rs.dns-oarc.net txt

Es ist wichtig im Hinterkopf zu behalten, dass die receive buffer Größe eine "hop-by-hop" Definition ist. Der Parameter beeinflusst nur die Kommunikation zwischen dem resolver und dem OARC Server.

Nominum CNS

$ dig tcf.rs.dns-oarc.net txt

Der spezielle Parameter tcf sorgt dafür das der Server das TC bit setzt, wenn die Anfrage nicht den EDNS pseudo-record gesetzt hat. Das sorgt dafür, dass CNS erneut eine Anfrage mit EDNS durchführt.