OpenWRT DDNS: Difference between revisions

mNo edit summary
 
Line 2: Line 2:


To help readers understand things, the terms "user name" and "password" are used in place of [[wikipedia:TSIG|TSIG]] sometimes.  Functionally, both are the same.  Anyway, the point is to avoid getting sidetracked on the TSIG subject and putting the focus on DDNS and BIND / NAMED.
To help readers understand things, the terms "user name" and "password" are used in place of [[wikipedia:TSIG|TSIG]] sometimes.  Functionally, both are the same.  Anyway, the point is to avoid getting sidetracked on the TSIG subject and putting the focus on DDNS and BIND / NAMED.
==== 2026 Update ====
The DDNS scripts are hopelessly stupid.  They work, but are missing so many things.  Like what?  Well, as Henry Ford said in a similar fashion, "You can have any password, encrypted with any encryption you want as long as it is hmac-md5."  Why?  It isn't NSUPDATE's fault, nor that of any modern BIND / NAMED Server.  Then what is it?  It's the script that calls NSUPDATE and the Directives available in OpenWRT's DDNS /etc/config/ddns Config File.  '''There's no way to stipulate any type of password encryption!''' 
Solution: Cram it into the username Directive.  Example;
option username 'ddns' (the documented method)
option username 'hmac-sha256:ddns' (the undocumented method of passing the encryption type through the DDNS Script to the NSUPDATE Command)
Why does that work?  Well, in the DDNS Script, the NSUPDATE Command is 'assembled' from variables in the .../ddns Config File, where it works out essentially like this;
<code>nsupdate -d [server WhatEverDNSServer] [key hmac-sha256:ddns WhatEverSecret] [update delete WhatEverHostName A] [update add WhatEverHostName S 600 A WhatEverIPAddress] [show] [send] [answer] [quit]</code> (keep in mind, the command as written here won't work, just an easy way to mentally see it)
However in reality, this is more similar to what actually happens in the script: <code>printf '%s\n' 'server WhatEverDNSServer' 'key hmac-sha256:ddns WhatEverSecret' 'update delete WhatEverHostName  A' 'update add WhatEverHostName  600 A WhatEverIPAddress' 'show' 'send' 'answer' 'quit' | nsupdate -d</code> (with all the strings being piped into NSUPDATE)
It just so happens that in the Command Syntax, 'hmac-sha256:', can be wedge in before the user name in the Config File's Directive, and then happens to get inserted into the perfect spot for where it is 'injected' into the NSUPDATE Command.
Will someone fix it in the future?  Probably.
Will it break this workaround?  Probably.
So they won't think to incorporate the workaround into the future fix and keep the workaround working?  Probably not.


===Problems===
===Problems===