DEV Community

R
R

Posted on

Configuring OpenWRT DDNS for freedns.afraid.org

Overview

freedns.afraid.org is a DNS provider that offers free registration of subdomains on a long list of "public" (shared) top-level domains.
This is a more friendly alternative for use with Dynamic DNS clients, than many similar services, because it does not require a periodic "manual" intervention to renew a registered subdomain just to keep it active. Other such services seem to use the "manual renewal" as a tactic to "inconvenience" people into paying for their service.

Setting up the DDNS client in OpenWRT to monitor for changes in a dynamic IP address, and update freedns.afraid.org, is a little confusing, because the DDNS scripts do NOT use their "Direct URL" approach for IP updates.

Official Docs

There is a guide in their docs that might work with some OpenWRT configurations, but makes some assumptions that were wrong in my case for the DDNS client option. The cron + curl option probably works, but isn't the usual/proper way to have OpenWRT handle DNS updates.

"Direct URL" vs. DDNS Client

"Direct URL"

The biggest source of confusion while setting this up came from what freedns.afraid.org calls the "Direct URL." This URL has the path /dynamic/update.php?{authtoken}. It is intended to be called/fetched from anywhere within a NAT network, and uses the originating IP for the request. The token embeds authentication and the reference to the subdomain, so it has no other parameters. This URL, and its "token" are NOT used by the DDNS client.

DDNS Client

freedns.afraid.org ALSO supports typical ddns client URLs with the path /nic/update, which accepts various URL parameters like hostname, and myip. THIS is what the OpenWRT DDNS client update script generates and uses. Authentication for this update option at freedns.afraid.org is HTTP basic, and requires the username:password for the freedns.afraid.org account, NOT the token, and NOT the FQDN of the subdomain (as the line option username 'yourhostname' in the docs incorrectly suggests).

DDNS IP resolution within NAT

One important aspect of the OpenWRT setup is whether the OpenWRT router is behind one or more NAT (network address translation) layers. If so, the default wan option for IP address source WON'T WORK, since it will discover an IP address that is still "hidden" within the private network. The DDNS client needs to reach outside the NAT/private network to get the "public facing" IP. See instructions below re: using the URL option instead.

How To

Now, with some of the confusing bits cleared up (let's hope), here are the steps to get things going.

  1. Sign up an account at freedns.afraid.org
  2. Decide on a suitable subdomain name, and add it to the account under one of the public domains controlled by freedns.afraid.org.
  3. If not already installed, add the DDNS client/service to OpenWRT.
  4. Add a DDNS "service" for freedns.afraid.org (using an example FQDN of mychosenname.example.com) (names/values in parens are for direct option entries in /etc/config/ddns without LuCI UI)
    • Lookup Hostname (lookup_host): mychosenname.example.com
    • DDNS Service Provider (service_name): Choose "afraid.org-basicauth"
    • Domain (domain): mychosenname.example.com
    • Username (username): freedns.afraid.org account username
    • Password (password): freedns.afraid.org account password
  5. Switch the DDNS service from wan to URL-based IP lookup (Advanced tab in LuCI). This uses the checkip.dyndns.com utility to reach all the way out from all internal network layers and echo back the "public" IP, instead of resolving the first-layer private address (i.e. when the "wan" side of an internal router is already within a NAT/private network).

Top comments (0)