BIND ist sehr streng was Syntax und korrektes Konfigurieren an geht und es verzeiht selbst fehlende Punktzeichen nicht. Umso aufwendiger kann eine Fehlerbehebung werden. nsupdate selber kann bereits unterschiedliche Fehler deklarieren. Diese und Wege zur Fehlereingrenzung und -behebung sollen hier angesprochen werden.
Im Normalfall liefert send von nsupdate keine Rückmeldung, sofern die Aktualisierung erfolgreich verlaufen ist.
Erhält man eine Ausgabe wie
; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)
dann liegt meistens die Ursache in einem fehlerhaften Schlüssel oder in der fehlerhaften Angabe des Keys. Das kann zum Beispiel passieren, wenn ein falscher Schlüsselname oder der falsche Algorithmus beim Befehl key oder der Option -k angegeben wurde.
Eine äquivalente Log-Meldung in /var/log/messages, /var/bind/security_info.log oder journalctl zeigt sich so:
22-Feb-2018 11:55:03.991 error: client 178.25.30.4#56421: request has invalid signature: TSIG ddns.example.org: tsig verify failure (BADKEY)
Mit NOTAUTH ist lediglich „not authoritative“ gemeint. Das bedeutet, dass man z.B. versucht den lokalen Caching DNS zu verändern. Allerdings passiert das bereits ungewollt relativ leicht in Verbindung mit einer umfangreicheren BIND-Konfiguration mit beispielsweise Views. Der gängigste Fall dürfte sein, dass man einfach in der falschen View landet. Hier hilft es unter Umständen die interne View anzupassen.
Erhält man von nsupdate auf ein send nachfolgende Fehlermeldung zurück, dann deutet das entweder auf eine Fehlkonfiguration der Parameter der Konfigurationsoption update-policy in der Konfigurationsdatei /etc/named.conf respektive /etc/bind/named.conf.local oder auf eine falsche Angabe innerhalb von nsupdate im Bezug auf die zu ändernden DNS-Einträge hin.
Die Log-Meldung gestaltet sich dann meistens wie folgt:
26-Feb-2018 17:58:14.244 info: client 178.174.206.155#39513/key ddns.example.org: updating zone 'example.org/IN': update failed: rejected by secure update (REFUSED)
Hier hilft weiter, was an anderer Stelle bereits erwähnt wurde. BIND erstellt bei erfolgreichem Update von der jeweiligen Zonendatei eine .jnl-Datei in demselben Verzeichnis an. Sobald jetzt die dazugehörige Zonendatei geändert wird - und sei es nur die Serial number - dann tritt dieser Fehler auf. Hier hilft es nur, die .jnl-Datei zu löschen und die Zonendatei mit einer neuen Serial number zu versehen, um dann BIND neu zu starten.
Meistens bietet nsupdate zuerst die Meldung ; Communication with server failed: timed out an. Das kann Vieles bedeuten, unter anderem eben auch, dass wegen einer Firewall die Verbindung zum BIND-Server verweigert wird. So ist der erste Schritt, die offenen Ports an dem Server zu überprüfen:
# nmap dns.example.org
Starting Nmap 6.47 at 2018-02-27 09:43 CET
Nmap scan report for dns.example.org (178.65.12.2)
Host is up (0.038s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp closed http
443/tcp closed https
3128/tcp closed squid-http
Nmap done: 1 IP address (1 host up) scanned in 21.43 seconds
Mit dem Portscanner nmap lässt sich sehr leicht anzeigen, welche Ports und vor allem ob Port 53 offen ist.
Aber auch nsupdate bietet weitere Möglichkeiten aussagekräftigere Infomrationen zu liefern. So schalten die Optionen -v und -L 3 auf Verbose und Debuging-Level 3 um. Zusätzlich zeigt show die aktuelle Nachricht an, die alle seit dem letzten Senden angegebenen Voraussetzungen und Aktualisierungen enthält. Während answer die Antwort anzeigt.
# nsupdate -v -L 3 -k /etc/ssl/Kdyndns.example.org.+163+46242.private
27-Feb-2018 18:36:48.223 dns_requestmgr_create
27-Feb-2018 18:36:48.224 dns_requestmgr_create: 0x74d05f08
> server ns.example.org
> zone example.org
> update delete dyndns.example.org
> update add dndns.example.org 18000 A 84.189.213.55
> send
27-Feb-2018 18:37:28.194 dns_request_createvia
27-Feb-2018 18:37:28.194 request_render
27-Feb-2018 18:37:28.194 requestmgr_attach: 0x74d05f08: eref 1 iref 1
27-Feb-2018 18:37:28.194 mgr_gethash
27-Feb-2018 18:37:28.195 dns_request_createvia: request 0x74c48008
27-Feb-2018 18:37:28.230 req_connected: request 0x74c48008
27-Feb-2018 18:37:28.230 req_send: request 0x74c48008
27-Feb-2018 18:37:28.231 req_senddone: request 0x74c48008
27-Feb-2018 18:37:28.266 req_response: request 0x74c48008: unexpected error
27-Feb-2018 18:37:28.266 req_cancel: request 0x74c48008
27-Feb-2018 18:37:28.266 req_sendevent: request 0x74c48008
; Communication with server failed: unexpected error
27-Feb-2018 18:37:28.266 dns_request_destroy: request 0x74c48008
27-Feb-2018 18:37:28.266 req_destroy: request 0x74c48008
27-Feb-2018 18:37:28.266 requestmgr_detach: 0x74d05f08: eref 1 iref 0
Aber auch das Mitlesen des Netzwerkverkehrs sowohl an der Ethernet-Schnittstelle des Clients, als auch an der Ethernet-Karte des BIND-Servers hilft bei der Fehlereingrenzung. So lauscht tcpdump hier
tcpdump -vvveni eth0 port 53
nicht nur an eth0, sondern filtert auch alle Datenpakete außer die des DNS-Service heraus. Mit -vvv erhält man eine extrem ausführliche Ausgabe, während -n führt eine Anzeige der IP- und Portnummern anstelle von Namen und -e für die Anzeige der Ethernetaddressen sorgt.