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.
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 126.96.36.199#56421: request has invalid signature: TSIG ddns.example.org: tsig verify failure (BADKEY)
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.
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 188.8.131.52#39513/key ddns.example.org: updating zone 'example.org/IN': update failed: rejected by secure update (REFUSED)
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.
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 (184.108.40.206)
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 220.127.116.11
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
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.