OpenWRT DDNS: Difference between revisions

Line 61:

===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 [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.

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.

==== Directives for /etc/bind/named.conf ====

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

key "ddns" {

algorithm hmac-md5;

secret "WhatEverMD5EncryptedPassword";

};

zone "WhatEverDomainName.WhatEverSuffix" {

type master;

allow-update {

key ddns;

};

file "/etc/bind/masters/WhatEverDomainName.WhatEverSuffix.hosts";

};

</syntaxhighlight>

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

~~=== Generating~~ a ~~"User Name" / "Password" for the above Server Configuration ===~~

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

=== File Permissions for BIND / NAMED Daemon / Server ===

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

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

====Secure Encrypted Communication Between Client and Server====

...coming soon.

@@ Line 61: / Line 61: @@
 ===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 [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.
+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.
+==== Directives for /etc/bind/named.conf ====
 Below are the directives to add to named.conf (in OpenWRT, the path is /etc/bind/named.conf);<syntaxhighlight lang="text">
 key "ddns" {
-      algorithm hmac-md5;
+     algorithm hmac-md5;
-      secret "WhatEverMD5EncryptedPassword";
+     secret "WhatEverMD5EncryptedPassword";
 };
+zone "WhatEverDomainName.WhatEverSuffix" {
+     type master;
+     allow-update {
+     key ddns;
+     };
+     file "/etc/bind/masters/WhatEverDomainName.WhatEverSuffix.hosts";
+     };
 </syntaxhighlight>
-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 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
-=== Generating a "User Name" / "Password" for the above Server Configuration ===
-As noted, the DDNS Scripts only seem capable of using passwords that have been encrypted with MD5 (HMAC-MD5).  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 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.
-=== File Permissions for BIND / NAMED Daemon / Server ===
+====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)
+*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===
+====Secure Encrypted Communication Between Client and Server====
 ...coming soon.