LINUXMAKER, OpenSource, Tutorials

Detecting the errors and error sources with nsupdate

BIND is very strict about syntax and configuring and it does not forgive missing dot characters. The more complex a troubleshooting can be. nsupdate itself can already declare different errors. These ways and means for error limitation and elimination are to be addressed here.

Normally, send of nsupdate does not return if the update was successful.

NOTAUTH(BADKEY)

If you get an output like

; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)

then most of the time the cause lies in a faulty key or in the incorrect indication of the key. This can happen, for example, if an incorrect key name or the wrong algorithm was specified with the key command or the -k option.
An equivalent log message in /var/log/messages, /var/bind/security_info.log or journalctl looks like this:

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)

update failed: NOTAUTH

NOTAUTH means only "not authoritative". This means that, e.g. tries to change the local caching DNS. However, this happens quite unintentionally relatively easily in connection with a more extensive BIND configuration with, for example, views. The most common case may be that you just land in the wrong view. Here it may help to adjust the internal view.

update failed: REFUSED

Receiving the following error message from nsupdate to a send indicates either a misconfiguration of the parameters of the update-policy configuration option in the configuration file /etc/named.conf or /etc/bind/named.conf.local or an incorrect specification within nsupdate with respect to the DNS records being changed.

The log message is then usually as follows:

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)

req_response: request 0x74c62008: unexpected error

Here helps, what has already been mentioned elsewhere. BIND will create a .jnl file in the same directory if the respective zone file is successfully updated. As soon as the associated zone file is changed - even if it is just the serial number - this error occurs. Here it only helps to delete the .jnl file and provide the zone file with a new serial number, in order to then restart BIND.

Procedure for troubleshooting

Most of the time, nsupdate will provide the message first; Communication with server failed: timed out on. This can mean a lot, including the fact that because of a firewall the connection to the BIND server is denied. So, the first step is to check the open ports on the server:

# 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

With the port scanner nmap can be very easily show which ports and especially if port 53 is open.

But also nsupdate offers further possibilities to provide more informative information. For example, options -v and -L 3 switch to verbose and debug level 3. In addition, show displays the current message, which contains all the prerequisites and updates since the last submission. While answer displays the answer.

# 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

Network traffic sniffing

However, reading the network traffic both on the Ethernet interface of the client and on the Ethernet card of the BIND server also helps to isolate the error. So listen to tcpdump here

tcpdump -vvveni eth0 port 53

not only eth0, but also filters out all data packets except the DNS service. With -vvv one receives an extremely detailed output, while -n leads a display of the IP and port numbers instead of names and -e provides for the display of the Ethernetaddresses.