Dynamic DNS using dynv6.com and DD-WRT

As of DD-WRT v3.0-r33772 (16/11/2017), DD-WRT's DDNS settings do not offer presets for dynv6.com. Unfortunately, the instructions for the »custom« settings of DD-WRT's DDNS feature are even more opaque than inadyn's man page. After some trial and error, I ended up with the following working setup.

DDNS Service

Custom

DYNDNS Server

dynv6.com

Username

user

Password

password

Hostname

your host name

URL

/api/update?ipv4=auto&ipv6=auto&token=your token&hostname=

Note that the username and password settings aren't used by dynv6.com, but they cannot be empty because DD-WRT then refuses to start the inadyn service.

You can find out the value for token by logging into your dynv6.com account. The settings are chosen to update the IPv4 or IPv6 address to the address from which the request is received. I have not investigated how to update both protocols at the same time.

The host name you enter into the corresponding field is automatically appended to the URL, which is why that parameter comes last without a value.

If you would like to see what's happening, you can add --verbose 5 to the »Additional DDNS Options« and the log file shown at the bottom of the page will contain more information.

Correct local domain and host-name DD-WRT setup

For a long time, I've struggled with inconsistent results for name queries on my local network. For example, sometimes OS X (El Capitan) couldn't ping a host by name while dig (host, nslookup) worked fine.

Also, I had never really tried to understand several options in the DD-WRT setup for domain and host names and the way they affected dnsmasq's configuration, the default DHCP and DNS server on DD-WRT.

My situation is that of a typical home user with a DHCP-assigned IPv4 address and no public host name or top-level domain.

As it turned out, I had got the setup wrong: the »hostname« and »domain name« on the main setup page refer to DHCP options sent to the ISP by the router's DHCP client, udhcpc. My ISP doesn't require any of those, so the fields should be left blank on my setup.

Instead, the right place to set the router's host name is the aptly-named »Router name« field.

The correct place to define the top-level domain of the local network is the »domain name« field in the »DHCP Server« section on the »Services« tab. In addition, »Used domain« must be set to »LAN and WLAN« instead of »WAN« because we don't actually have a »WAN« domain.

By the way, I chose »lan« as the name of my local domain because »local« has been specified for use by mDNS.

As a result, the router's host name is correctly entered into /etc/hosts (both with and without my local domain) and dnsmasq resolves names of local DHCP clients both in their short and long forms.

Broken "DNS relay" in DLink DIR-615

In my student days, I owned a DLink DI-624+ router. It needed resetting at least once a day and even more often under heavy use. Not exactly the behaviour you look for in a router... After this experience I vowed never to waste time on DLink hardware again.

As it happens, I just got a DLink DIR-615 router with my new cable connection. It has a setting to turn the "DNS relay" function on or off. I left it turned on because it was the default and I've always configured my routers to act as DNS servers -- if only because it enable neat little tricks like accessing the router as "dlinkrouter" (which doesn't work over WiFi, by the way).

I then noticed that my IM client failed to connect to several of my Jabber accounts (also known as XMPP). As it happens, the SRV records for those accounts which are required to find the Jabber server for a given e-mail address were not returned by the DNS server. After some digging around (intended pun: dig srv _jabber._tcp.domain.com) it eventually dawned on me that the "DNS relay" in the DLink router was eating those SRV replies.

Needless to say, after turning off the relay "feature," my IM clients could happily connect to all accounts again.

I'm now replacing the DLink router with an AVM Fritz!Box I have lying around...

Edit (January 2015): salvation for the DLink router was found at DD-WRT.