I am using the RouterOS DHCP server to assign IP addresses to client systems. This is working well so far, but I would like to have it update my Bind DNS server that is running on a separate server. I have seen the contributed scripts for doing this and intend to use one of them as the basis for writing my own script. But when I try to use "/tool/dns-update", I cannot find a way to specify the port number that my DNS server is listening on for control commands. By default the DNS server listens on port 953, but by using tcpdump on my server I see that RouterOS appears to be sending control commands over port 53, the DNS protocol port. Is there a way to specify a different port for dns-update to send commands over in RouterOS?

I am using a hEX S router running version 7.13

Thanks,

Mark

TCP port 953 is RNDC port not DNS service port. All DNS clients uses standard DNS port (UDP/TCP 53) for queries or update request and that port must be accesible for DNS service to work.

I don't think you can change the port on the /tool/dns-update command.

However, there is likely a workaround by doing a dst-nat in /ip/firewall/nat to change the port. Exactly how to do that depend on your topology/config, but dst-nat should be able re-map the port.

Yes, but this statement "By default the DNS server listens on port 953..." not sure is correct (unless bind config is modified for DNS service to listen on that port, but then it is not default), it's default for RNDC port and if is even remapped to that port with nat /tool/dns-update will not work since is different protocol.

Yes, but this statement "By default the DNS server listens on port 953..." not sure is correct (unless bind config is modified for DNS service to listen on that port, but then it is not default), it's default for RNDC port and if is even remapped to that port with nat /tool/dns-update will not work since is different protocol.

You have a point. I've never used RNDC with BIND – but 953 is the port for it.... So even if you could control the port (or dst-nat), the `rndc` commands (https://bind9.readthedocs.io/en/v9.18.2 ... ol-utility) are NOT same as standard RFC-2136 DDNS updates used by /tool/dns-update.

See BIND9 docs, https://bind9.readthedocs.io/en/v9.18.2 ... mic-update for how to setup your zone file (not rdnc.conf) for it to work with RouterOS's dns-update (which follows RFC-2136):

Dynamic update is enabled by including an allow-update or an update-policy clause in the zone statement.

See BIND9 docs, https://bind9.readthedocs.io/en/v9.18.2 ... mic-update for how to setup your zone file (not rdnc.conf) for it to work with RouterOS's dns-update (which follows RFC-2136):

Dynamic update is enabled by including an allow-update or an update-policy clause in the zone statement.

Over DNS protocol not RNDC to be clear for OP

It appears that I am mistaken. Prior to implementing MikroTik routers, addresses were provided by DHCP running on the same server as my DNS. The key DHCP and DNS used to authenticate with was named rndc-key and in fact RNDC on this server used that same key. Therefore I assumed that DHCP used RNDC commands to make its updates. But it appears that this is not true. DHCP appears to make updates through the standard DNS port 53.

My first attempts to send DNS updates from the Mikrotik router failed and when I saw that the messages were being delivered to port 53, I thought that this was not correct and hence my request for help. I now see in the named.log file that the actual block is that DNS is refusing the key that I have put into the router. I have verified that they appear to be the same, but something is wrong somewhere. But now I see that it is an authentication issue. At a minimum, I will start with a new, separate key that is different from the RNDC key.

I solved the authentication issue (I was using a hmac-sha256 key, not hmac-md5) and I am now able to add resource records into my DNS server from my MikroTik router. But I cannot find a way to remove records. That is not mentioned in the documentation as far as I can tell. DOes anyone have an answer for that?

It's DNS.. so you use TTL to control when it gets removed. You should be able to replace, but there is no "remove" – it expires based on what you set in dns-update's ttl=.

I suspected it was going to be something like that. The Linux nsupdate command has a delete command and I was hoping for something similar here. It is what it is. I will work with that, then.