Dynamic DNS update problems (TSIG)

RouterOS General
1

I’m trying to get a MikroTik router running 2.9rc6 to send a dynamic DNS update
to one of our own nameservers (running bind 9.2).

Analyzing the traffic between the router and the nameserver shows that the router
is sending a TSIG signed UPDATE query signed with HMAC-MD5. That’s fine, because
that’s exactly what our bind server is expecting, but I’m having problems to get our
bind server to accept the TSIG key from the MikroTik device.

Sending the update with the nsupdate program that comes with bind works just fine.

Here is what I’m doing with nsupdate:

nsupdate -k Ktest.tmr-vpn.net.+157+21943.private -v update.txt

where the key file looks like this

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: MXiaoTeY6RvdycbeINzm4Wj2qW7Ikamn2iI80+vhIxHD6D8DUWu7JsOmEG6o1nR/DHjrOGeUq5/Hqz9cA6Io5g==

and the nsupdate command file looks like this

server xx.yy.tmr.net
zone tmr-vpn.net
update delete test.tmr-vpn.net. A
update add test.tmr-vpn.net. 86400 A 1.2.3.4
show
send

and this works just fine. Now I’m trying to do exactly the same update from the MikroTik router, so I did this

/tool dns-update zone=tmr-vpn.net dns-server=x.y.z.z \
\... name=test address=1.2.3.4 \
\... key-name=test.tmr-vpn.net \
\... key="MXiaoTeY6RvdycbeINzm4Wj2qW7Ikamn2iI80+vhIxHD6D8DUWu7JsOmEG6o1nR/DHjrOGeUq5/Hqz9cA6Io5g=="

but the bind server always rejects the update with an error saying that the key is bad.

What am I doing wrong? Do I need to specify the key in some other format or something?

In addition, I noticed that the update that is sent from the MikroTik router to the DNS server
does not delete the A record prior to sending the (maybe) new one. That’s no problem as
long as the address remains the same (but then, what’s the point of the update), but as soon
as the address in the update differs from the one that is already stored in bind’s zone for the
client, then this would add an additional A record for the same client, and so on…
So how is this supposed to work?

–Tom

2

Check the time stamps on both machines. The HMAC signature has to be within a few minutes of each other…

Sam

3

Sam,

thanks for your suggestion. I know that the time on both devices needs to be correct.
I have both the MikroTik router and the DNS server synchronised by NTP, in fact the
DNS server is also the NTP server the MikroTik gets its time from. I’ve checked the time to
be correct on both devices, including timezone.

–Tom

4

but the bind server always rejects the update with an error saying that the key is bad.

Does the above quote come from the BIND named.log file, or somewhere else? Check the actual named.log file to see if there are specific errors. If you need to increase the logging you can use RNDC to up the debug level.

My guess is you are having the same bug as I am with packet sniffing. The routers time is in sync and shows the correct time, but it is ignored and a 1970s date is used for the timestamps instead.

Sam

5

Sam,

The bind logfile contains the following when I successfully update using nsupdate from a UNIX client

Jun 25 21:24:36.355 update: client 212.23.xx.yy#24036: updating zone 'tmr-vpn.net/IN': deleting an rrset
Jun 25 21:24:36.355 update: client 212.23.xx.yy#24036: updating zone 'tmr-vpn.net/IN': adding an RR

and here is the failure that is logged when I try to update from the MikroTik router

Jun 25 21:27:13.577 security: client 212.23.xx.zz#1029: request has invalid signature: tsig verify failure

I’ve done some more packet sniffing with ethereal to check on the 1970s date bug you mention. The date/time of the TSIG seem to be correct (see Time signed: fields below), but there are other minor differences as can be seen from the screenshots below. The first picture is from a packet captured from the UNIX nsupdate client, which works:

Note that the Algorithm name: hmac-md5.sig-alg.reg.int is all lowercase, and that the Original id: contains a nonzero value.

For comparison, here is the picture of a packet sent by the MikroTik router:

Note that this time the Algorithm name: HMAC-MD5.SIG-ALG.REG.INT is all upper case, and that the Original id: contains a zero value.

I don’t know if any of this is relevant, though, but these are the only things that are obviously different.

–Tom

6

Look at the rest of that dns update packet … if the id is not 0 then you have found your problem. That ‘0’ should be the dns id from the header of that same packet. If they do not match then you have a broken signature.

PS - This should be reported to support@ so they may fix it. I’ve emailed many times and never gotten a response, but at least it puts it on their to do list (hopefully). Also, since this is rc6 it should be posted in the Beta forum not this one…

Sam

7

You’re on the right track. The Transaction id of the DNS update packet differs from what is given as Original id in the TSIG record. In fact, further testing shows that the Original id seems to always be ‘0’, while the Transaction id is dynamically changing between tests.

What is cause and what is effect here? Does the Original id get set to ‘0’ because the signature is miscalculated or does the signature get miscalculated because the Original id is ‘0’ even when it should be something else and the Original id takes part in the calculation of the signature, thereby messing it up?

I’ll point support@mikrotik.com to this discussion.


–Tom

8

The original id is part of the dns query - its a random integer so that the dns parties can keep track of their queries. Part of the TSIG signature is this original ID - and if MT is using 0 for it then the signature will not compute because it doesn’t match what it signed. I know this because I just finished writing a vb.net project that does TSIG updates to BIND… and ran into the same problem when not using the same id as the header packet.

Sam

9

http://wiki.mikrotik.com/wiki/Manual:Tools/Dynamic_DNS

This command (/tool dns-update) is need to run in scripts?
If so, what is the minimal script, if I use to one public IP?

Thank’s!