OpenWRT DDNS

Wiki.TerraBase.info
Revision as of 12:48, 1 December 2020 by Root (talk | contribs) (→‎Encryption)
Jump to navigation Jump to search

This article was written about DDNS (Dynamic DNS (Domain Naming System (not Service))) on OpenWRT, but some of it could apply to DDNS using other platforms. On the server side, BIND / NAMED is used instead of the default OpenWRT DNS Daemon / Service, DNSMASQ. DDNS-SCRIPTS is / are the service(s) used on the client side.

To help readers understand things, the terms "user name" and "password" are used in place of 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.

Problems

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).

Encryption

The DDNS Client scripts for updating a DNS Server via NSUPDATE expects the "password" (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 this documentation, it is sort of implied that BIND / NAMED only uses MD5 (HMAC-MD5) when using TSIG.

Permissions

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).

Documenation

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

Installation and Configuration

Installation for Client and Server

opkg update

Client: opkg install ddns-scripts ddns-scripts_nsupdates luci-app-ddns wget curl *

Server: opkg install bind-server bind-tools (bind-tools includes: bind-rndc bind-check, plus dependencies are all installed)**

If it isn't obvious, the client and server software will not be installed on the same router as DNS server software such as BIND / NAMED rely on having a static IP Address assigned to the OS they're installed on.

See the BIND / NAMED section in this article for additional information on configuration.

The LuCI GUI for the DDNS client is located here: Services, Dynamic DNS

See the Webmin section of this article for a GUI for BIND / NAMED.

* This OpenWRT article discusses and addresses several subjects related to WGET and CURL.

** 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.

Configuration for Client

Below is a working /etc/config/ddns configuration file for DDNS Scripts; 

config ddns 'global'
	option ddns_dateformat '%F %R'
	option ddns_loglines '250'
	option upd_privateip '0'
	option use_curl '1'

config service 'WhatEverArbitraryName'
	option service_name 'bind-nsupdate'
	option lookup_host 'WhatEverHostName.WhatEverDomainName.WhatEverSuffix'
	option username 'WhatEverUserName'
	option password 'WhatEverMD5EncryptedPassword'
	option domain 'WhatEverHostName.WhatEverDomainName.WhatEverSuffix'
	option enabled '1'
	option ip_source 'web'
	option ip_url 'https://domains.google.com/checkip'
	option bind_network 'wan'
	option force_ipversion '1'
	option interface 'wan'
	option dns_server 'WhatEverDNSServer.WhatEverDomainName.WhatEverSuffix'

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).

Additional Configuration Example for a Router with Dual WAN Capability

The below example assumes the WAN interfaces (OpenWRT perspective, not from ifconfig perspective) are "wan" and "wwan"

config ddns 'global'
	option ddns_dateformat '%F %R'
	option ddns_loglines '250'
	option upd_privateip '0'
	option use_curl '1'

config service 'WhatEverArbitraryName'
	option service_name 'bind-nsupdate'
	option lookup_host 'WhatEverHostName.WhatEverDomainName.WhatEverSuffix'
	option username 'WhatEverUserName'
	option password 'WhatEverMD5EncryptedPassword'
	option domain 'WhatEverHostName.WhatEverDomainName.WhatEverSuffix'
	option enabled '1'
	option ip_source 'web'
	option ip_url 'https://domains.google.com/checkip'
	option bind_network 'wan'
	option force_ipversion '1'
	option interface 'wan'
	option dns_server 'WhatEverDNSServer.WhatEverDomainName.WhatEverSuffix'

config service 'WhatEverArbitraryName2'
	option service_name 'bind-nsupdate'
	option lookup_host 'WhatEverHostName2.WhatEverDomainName.WhatEverSuffix'
	option username 'WhatEverUserName'
	option password 'WhatEverMD5EncryptedPassword'
	option domain 'WhatEverHostName2.WhatEverDomain.WhatEverDomainName.WhatEverSuffix'
	option enabled '1'
	option ip_source 'web'
	option ip_url 'https://domains.google.com/checkip'
	option bind_network 'wwan'
	option force_ipversion '1'
	option interface 'wwan'
	option dns_server 'WhatEverDNSServer.WhatEverDomainName.WhatEverSuffix'

SPECIAL NOTES;

  • 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)

Configuration for Server

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.

Generating a "User Name" / "Password"

As noted, the DDNS Scripts only seem capable of using passwords that have been encrypted with MD5 (HMAC-MD5). Some 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.

And also, as noted previously, the dnssec-keygen program (opkg install bind-dnssec) provided by OpenWRT does not support generating MD5 passwords. If one attempts to do so, an error occurs. Solution, again as noted previously, use a different CentOS, or whatever Linux distribution to generate an MD5 encrypted "password" / "secret"

This command will generate a "password" / "secret" for the "user" named "ddns": dnssec-keygen -a HMAC-MD5 -b 512 -n USER ddns

The DDNS Script on the client will also complain that the "password isn't complex enough", but will still function, if a value of less than 512 is used in the above command.

Other utilities, noted 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.

Directives for /etc/bind/named.conf

Below are the directives to add to named.conf (in OpenWRT, the path is /etc/bind/named.conf);

key "ddns" {
     algorithm hmac-md5;
     secret "WhatEverMD5EncryptedPassword";
};

zone "WhatEverDomainName.WhatEverSuffix" {
     type master;
     allow-update {
     key ddns;
     };
     file "/etc/bind/masters/WhatEverDomainName.WhatEverSuffix.hosts";
     };

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

File Permissions for BIND / NAMED Daemon / Server

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.

  • chown bind:bind /etc/bind (for example, as the location for files can anywhere)

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.

Secure Encrypted Communication Between Client and Server

...coming soon.

Troubleshooting

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

For troubleshooting on the server side, the below directives can be added to /etc/bind/named.conf for a "Kick Ash" * amount of logging for BIND / NAMED;

logging {
    channel default_log {
          file "/tmp/log/named/default.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel general_log {
          file "/tmp/log/named/general.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel database_log {
          file "/tmp/log/named/database.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel security_log {
          file "/tmp/log/named/security.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel config_log {
          file "/tmp/log/named/config.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel resolver_log {
          file "/tmp/log/named/resolver.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel xfer-in_log {
          file "/tmp/log/named/xfer-in.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel xfer-out_log {
          file "/tmp/log/named/xfer-out.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel notify_log {
          file "/tmp/log/named/notify.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel client_log {
          file "/tmp/log/named/client.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel unmatched_log {
          file "/tmp/log/named/unmatched.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel queries_log {
          file "/tmp/log/named/queries.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel network_log {
          file "/tmp/log/named/network.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel update_log {
          file "/tmp/log/named/update.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel dispatch_log {
          file "/tmp/log/named/dispatch.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel dnssec_log {
          file "/tmp/log/named/dnssec.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };
    channel lame-servers_log {
          file "/tmp/log/named/lame-servers.log" versions 3 size 20m;
          print-time yes;
          print-category yes;
          print-severity yes;
          severity dynamic;
    };

    category default { default_log; };
    category general { general_log; };
    category database { database_log; };
    category security { security_log; };
    category config { config_log; };
    category resolver { resolver_log; };
    category xfer-in { xfer-in_log; };
    category xfer-out { xfer-out_log; };
    category notify { notify_log; };
    category client { client_log; };
    category unmatched { unmatched_log; };
    category queries { queries_log; };
    category network { network_log; };
    category update { update_log; };
    category dispatch { dispatch_log; };
    category dnssec { dnssec_log; };
    category lame-servers { lame-servers_log; };
};

Additional Subjects

DDNS on a Router Behind Another Router

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);

config ddns 'global'
        option upd_privateip '1'
        option use_curl '1'

config service 'WhatEverService1'
        option enabled '1'
        option interface 'wan1'
        option service_name 'WhatEverService'
        option lookup_host 'WhatEverHost1'
        option username 'WhatEverUserName'
        option password 'WhatEverPassword'
        option domain 'WhatEverDomain2'
        option ip_source 'web'
        option ip_url 'https://domains.google.com/checkip'
        option bind_network 'wan1'
        option force_ipversion '1'

config service 'WhatEverService2'
        option enabled '1'
        option interface 'wan2'
        option service_name 'WhatEverService'
        option lookup_host 'WhatEverHost2'
        option username 'WhatEverUserName'
        option password 'WhatEverPassword'
        option domain 'WhatEverDomain2'
        option ip_source 'web'
        option ip_url 'https://domains.google.com/checkip'
        option bind_network 'wan2'
        option force_ipversion '1'
  • Use the option use_curl '1' directive when using DDNS with a Dual WAN Router
  • If the router with the DDNS functionality is behind another router (like a hotspot, etc.), then the following directives should be configured for proper functionality;
    • use_curl '1'
    • interface 'WhatEverInterface' (not the "ifconfig" or "ip a" name, but the OpenWRT Name found in the LuCI GUI, Network, Interfaces)*
    • ip_source 'web'
    • ip_url 'WhatEverServiceLikeGoogle'
    • bind_network 'WhatEverInterface' (not the "ifconfig" or "ip a" name, but the OpenWRT Name found in the LuCI GUI, Network, Interfaces)*
    • force_ipversion '1'
    • ...and his requires CURL be installed: opkg install curl

* In the above example, wan1 and wan2 are just place holders. In real world circumstances, wan, wwan, etc. would be used, NOT eth1.2

The OpenWRT documentation states WGET is used by default, but for dual WAN routers, make sure the above noted use_curl directive is set.

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

Special Thanks

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

Retrieved from "https://wiki.terrabase.info/index.php?title=OpenWRT_DDNS&oldid=1242"