Difference between revisions of "OpenWRT DDNS"

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.

OK, first, there are some problems getting the entire DDNS infrastructure to work.  If you're not interested in these items, skip down a few sections (don't worry, they're addressed there in terms of proper configuration).

The DDNS Client scripts for updating a DNS Server via NSUPDATE expects the "password" ([[wikipedia:TSIG|TSIG]]) to be encrypted / signed using MD5 (HMAC-MD5).  The version of the DNSSEC-KEYGEN tool provided by OpenWRT, which is typically used for generating / encrypting / signing a "password" in this form does ''not'' support MD5 (HMAC-MD5).  Regardless of the arguments pertaining to MD5 encryption / signing, this issue presents a problem.  The workaround is easy if you've got a CentOS, Debian, Ubuntu, etc. version of Linux available, as their version of the DNSSEC-KEYGEN utility does support MD5 (HMAC-MD5).  As of 11.2020, there is very little information on this subject.  This web page notes the issue, but there is no answer: https://github.com/openwrt/packages/issues/8927  According to [https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch11_01.htm this] documentation, it is sort of implied that BIND / NAMED only uses MD5 (HMAC-MD5) when using [[wikipedia:TSIG|TSIG]].

Out of the box, the permissions on the /etc/bind Directory will cause issues (assuming that's where master and slave files are stored, CentOS stores them in /var/named for example).  Regardless of the location, the permissions must be set such that the BIND / NAMED Daemon / Service can write to the Directory (a specific example for this is 'journal' files).

OpenWRT provides documentation for DDNS (the client side of things, not the server side) here, https://openwrt.org/docs/guide-user/services/ddns/client and here, https://openwrt.org/docs/guide-user/base-system/ddns  It isn't the best written documentation in the world.  But those guys are busy with other stuff, so that's OK.  It also appears to be written by a non-English speaker, so be prepared for some bad grammar and sentences.  But again, that's fine, as that person speaks at least one more language than I do (that's a compliment to them).  There are also a couple of additional items that have been added to the DDNS Scripts that aren't addressed by the standard OpenWRT documentation and are only mentioned in passing here: https://github.com/openwrt/packages/issues/2348

opkg update

<nowiki>**</nowiki> It is necessary to disable the DNS functionality of DNSMASQ for BIND / NAMED to function properly.  If DHCPD is used, and none of DNSMASQ's functionality is necessary, it is highly recommended to remove DNSMASQ instead of disabling it.  Odd issues seem to crop up if it remains installed, even if disabled.  

Below is a working /etc/config/ddns configuration file for DDNS Scripts; <syntaxhighlight lang="text">

config ddns 'global'

It was found that WGET did not work reliably in situation where the router running the DDNS Client Scripts with a private WAN IP Address was behind another router with a public WAN IP Address.  So CURL was used to address the issue.  DD-WRT addresses this very issue with a radio button choice titled "Do not use external ip check" (worded poorly as negative questions are always a bit confusing), but OpenWRT offers no similar configuration via its GUI or in the configuration file (/etc/config/ddns).

The below example assumes the WAN interfaces (OpenWRT perspective, not from ''ifconfig'' perspective) are "wan" and "wwan"<syntaxhighlight lang="text">

config ddns 'global'

option interface 'wwan'

option dns_server 'WhatEverDNSServer.WhatEverDomainName.WhatEverSuffix'

*The OpenWRT DDNS Scripts do NOT like or tolerate dashes or hyphens ( - ) in the service name (IE: ''config service 'What-Ever-Name' will not work and result in nothing showing up in the LuCI GUI)''

*DDNS Scripts (and maybe BIND / NAMED) do NOT like or tolerate underscores ( _ ) in the ''lookup_host'' or ''domain'' directives (IE: What_Ever_Host_Name.WhatEverDomain.WhatEverSuffix will cause an error)

It is not the intent of this article to provide complete documentation on configuring a BIND / NAMED DNS server.  This section assumes one has a functioning BIND / NAMED DNS Daemon / Service running.

As noted, the DDNS Scripts only seem capable of using passwords that have been encrypted with MD5 (HMAC-MD5).  Some [https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch11_01.htm documentation] for BIND seems to indicate this is a choice made by BIND / NAMED.  DH and SHA256 encryption methods were attempted, but did NOT work.  An error in the DDNS log file indicated it was attempting to use an MD5 encrypted password, regardless of how the "password" / "secret" was encrypted.

Other utilities, noted [https://bind9.readthedocs.io/en/v9_16_5/advanced.html here], such as ''tsig-keygen'' and ''ddns-confgen'' can also generate the appropriate "user name" / "password".  But they are not available in any OpenWRT packages.

Below are the directives to add to named.conf (in OpenWRT, the path is /etc/bind/named.conf);<syntaxhighlight lang="text">

The above directives essentially adds a User Name / Password (in encrypted form) that the BIND / NAMED DNS Daemon / Service use to authenticate clients.  "ddns" is the User name and the text within, but not including the double quotes, is the password.  The zone directive allow-update is one of several ways to restrict dynamic updates (IE, restricting updates to a set group and preventing anyone in the world from sending updates).  The above ''allow-update'' directive allows anyone using the user name "ddns" (with the appropriate "password") to update the WhatEverDomain.WhatEverSuffix Domain (Example: Google.com).  More information on allow-update and update-policy can be found here: https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_02.htm

As it comes from OpenWRT, the bind-server (opkg install bind-server) does not include, specify, configure, or make provisions for any directories that have additional BIND / NAMED files for things such as master and slave zone storage files.  Whatever directory is configured for BIND / NAMED to uses for purposes such as that, it must have the proper permissions to create "journal files" as that's where DDNS Client updates are initially stored.  IE, updates are not written directly to WhatEverZoneFile.

The bind User and Group are configured when the bind-server package is installed.  If the BIND / NAMED Daemon / Service doesn't have write permissions, the journal file cannot be created.  It results in a very, very obscure error in one of the below mentioned log files.

...coming soon.

For troubleshooting on the client side, under Services, Dynamic DNS, Advanced Settings Tab, enable the Log to file Check Box.

</syntaxhighlight>

To get it to work properly, below is an example of a router with two WAN connections to the internet where both interfaces are behind other routers (IE, the router with the DDNS service has local IP Addresses assigned to its WAN interfaces);<syntaxhighlight lang="text">

config ddns 'global'

Some good hints came from here: https://github.com/openwrt/packages/issues/8277

It can happen...  It's possible an OpenWRT router could be located behind a service provider equipment that provides some sort of "pass through" functionality to the OpenWRT router.  If that's the case, it appears from testing the DDNS client service can detect the proper public IP Address, but will not report it through the "Interface Name" method or the "Network Name" method (described above).  No further testing was done to see if there were variations that could correct this minor issue as the "Web Service" method (like Google's) works as expected.

...as of early 2021, this section is not yet complete (and may never be completed because it would take less time to just switch from DD-WRT to OpenWRT)

Sadly, all of the below is predicated on having Entware installed on a DD-WRT router.  That's a bit of an undertaking, but is described here: [[Entware Installation on DD-WRT]]

If you don't want to try  installing Entware, then a good starting point might be the "Do NOT try these things..." in the next section (a bit ironic, but read the last paragraph of that section).

It was worth it to put this in here because it useful.  Unlike every other well meaning tutorial on this, it actually works (IE, the others don't)

Having made those disparaging remarks, the below configuration was based on all of the above (sort of).  So even though the above seems a bit derogatory, it isn't.  Thanks to the pioneering work of those nice people, the below configuration was created.

This is a prerequisite for having everything for DDNS on DD-WRT  

*Run this command: resolveip -4 www.google.com (and that will result in 172.217.6.36 or any number of other IP Addresses, depending on your physical location)

Several authors of several web pages stand out in terms of offering really good tips this article is based on.  The are noted below;