DDNS by SSL - plus config for afraid.org, duckdns.org, & dynu.com

I have configured my router TP-Link C7 v5 (running on a OpenWrt release 19.07.8 custom image) to update three DDNS subdomains by SSL.

All I did was to install packages wget and ca-certificates and enter these two additional lines to config blocks in /etc/config/ddns

        option 'use_https' '1'
        option 'cacert' '/etc/ssl/certs'

Updates work fine.


  1. How do I know that the update traffic (to the DDNS site servers) is using SSL?

  2. If I entered the above two lines into config, and the SSL somehow failed, would (a) plain text traffic go out instead (OpenWrt would have to choose to do so I believe) or would (b) the update simply fail? If (b), then the very success of update would tell me that SSL was working.


I will set out the config blocks I used for the 3 DDNS providers both for this question's sake and also because it took me some time to figure them out and another novice like myself may find them useful.


  • Do not use a dash (-) or period (.) in the value for config service line.
  • In all 3, I believe option interface 'wan' superfluous (as supplied by defaults). Have not tested (by deleting).
  • In all 3, I cause the router to use a Web site to find out its own public IP address. This way the router can sit behind another.
  • The password for afraid.org is the portion of URL after the question mark (?) in their so called "Direct URL". To see this URL, log in, click "Dynamic DNS" (in the left column), find your subdomain toward bottom, click link "Direct URL."
  • The password for duckdns.org is their so called "token."
  • Made-up names (e.g. subdomain) start with "cow."
  • Of the 3, the one I least recommend would be afraid.org, based on my experience in this post (it says basically that afraid.org is slow to be updated in LuCI): DDNS does not update LuCI's display

1. Config for afraid.org
config service 'afraid_ipv4'
	option lookup_host 'cowsubdom.mooo.com'
	option service_name 'afraid.org-keyauth'
	option ip_source 'web'
	option ip_url 'http://ipecho.net/plain'
	option interface 'wan'
	option 'use_https' '1'
	option 'cacert' '/etc/ssl/certs'
	option enabled '1'

2. Config for duckdns.org
config service 'duckdns_ipv4'
	option lookup_host 'cowsubdom.duckdns.org'
	option domain 'cowsubdom.duckdns.org'
	option password 'cow3id29-b8sk-b9sj-x9be-sblsifjse'
	option service_name 'duckdns.org'
	option ip_source 'web'
	option ip_url 'http://ipecho.net/plain'
	option interface 'wan'
	option 'use_https' '1'
	option 'cacert' '/etc/ssl/certs'
	option enabled '1'

3. Config for dynu.com
config service 'dynu_ipv4'
	option lookup_host 'cowsubdom.ddnsfree.com'
	option domain 'cowsubdom.ddnsfree.com'
	option username 'cowuser'
	option password 'cowpassword'
	option service_name 'dynu.com'
	option ip_source 'web'
	option ip_url 'http://checkip.dynu.com'
	option interface 'wan'
	option 'use_https' '1'
	option 'cacert' '/etc/ssl/certs'
	option enabled '1'

Use tcpdump and capture the traffic from the router to the update server.

I think the b


Thank you. I don't think I know how to limit the capture properly (never heard of tcpdump before today). This is what I tried.

What should the tcpdump command look like?

Try this: tcpdump -i any -evn -c 50 host www.duckdns.org


That totally worked! tcpdump confirms that all updating of the ddns server goes through the server's port 443.

This is what I did:

  • Manually set my ddns subdomains to arbitrary IP (e.g.
  • Quit Internet browser (so as to exclude any traffic by it)
  • SSH into OpenWrt router (in 3 separate Terminal instances)
  • Use tcpdump as follows (one provider for one Terminal)
tcpdump -i any -evn -c 200 host freedns.afraid.org
tcpdump -i any -evn -c 200 host www.duckdns.org
tcpdump -i any -evn -c 200 host api.dynu.com
  • See that all traffic has one of these two forms (where is my OpenWrt router's WAN IP as it sits behind another router): > >

Couple of things I noted:

  • Above command form captures traffic when my router corrects the provider server (i.e. gives it the actual router public IP), at the first available "update chance" (which happens every 10 minutes) .
  • The router, 10 minutes later, looks up the provider again and sees that it has now got the correct IP (as it should). Router then updates LuCI's display of "what the provider has for me." When this bit of traffic happens, tcpdump does not capture it. I believe it may be due to the looking-up going through a different (provider) host than the correcting (and so not being subject to the tcpdump command as I have it).
  • These tcpdump tests expose the problem of afraid.org in a more precise way. Router generally misses the first "chance" to update afraid.org, and the update takes place on the second "chance." Ten minutes later, router looks up afraid.org and somehow receives the idea that afraid.org still has the wrong IP ( and therefore corrects it again (generating tcpdump lines in my Terminal). This needless correcting happens 4 or 5 times before finally router sees that afraid.org has the correct IP, displays it on LuCI, and stops correcting.

Anyway, tcpdump was great! I can see myself using a lot. Thanks so very much!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.