ddns-scripts: Simultaneous update of A and AAAA records - Broken IPv6 support on dyn.com
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 4.6k
- Forks
- 4k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 134
Description
Maintainer: @\svlobanov
Environment: Linux OpenWrt 4.14.221 #0 SMP Mon Feb 15 15:22:37 2021 armv7l GNU/Linux
OpenWrt 19.07.7 r11306-c4a6851c72
ddns-scripts 2.7.8-14
Description:
The script dynamic_dns_updater.sh does not support updating both the A records, and the AAAA record.
With at last dyn.com, the two updates cannot be made independently.
If myip=nnn.nnn.nnn.nnn, the A record is updated and the AAAA record is deleted.
If myip=2011:.....:abcd, the AAAA record is updated and the A record is deleted.
The correct URL syntax required to update both records is: myip=IPv4,IPv6
Alternately, it seems that repeating the myip parameter works too, but there will be only one response good/nochg using the format IPv4,IPv6
It is not currently possible to update both records on dyn.com, and probably a number of other. The need to update only the AAAA record is probably very rare, and out of that rare situation, IPv6 support on dyn.com is broken, since it deletes the A record.
Suggested enhancement:
The updater script currently has the option use_ipv6 (Luci radiobuttons IPv4-Address and IPv6-Address) which controls which address it attempts to get using nslookup on the defined Lookup hostname (lookup_host). If a third option Both-Addresses was defined, it would be rather simple to get them from the output of nslookup:
root@OpenWrt:/usr/local/bin# nslookup critical-optimisation.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: critical-optimisation.com
Address 1: 176.137.81.126
Address 2: 2001:861:3205:7e13::905e
As far as I could see, if a custom script also returns both addresses, the remaining logics should be fine. There could be an issue with expansion of the IPv6, which takes place before the addresses are compared, but the custom script could take care of that as well.
In general a custom script to read the "local" IPs will be required for IPv6, because the ISP often only allocates a prefix. In my case, the DNS AAAA record points directly to a server in the LAN, placed behind the firewall. There is usually no NAT with IPv6.
My custom script is:
#!/bin/sh
CONFIG=/etc/get_ipv6.conf
DEFAULTS=/etc/get_ipv6.conf.defaults
config_read_file() {
(grep -E "^${2}=" -m 1 "${1}" 2>/dev/null || echo "VAR=__UNDEFINED__") | head -n 1 | cut -d '=' -f 2-;
}
config_get() {
val="$(config_read_file "${CONFIG}" "${1}")";
if [ "${val}" = "__UNDEFINED__" ]; then
val="$(config_read_file "${DEFAULTS}" "${1}")";
fi
printf -- "%s" "${val}";
}
main() {
interface=$(config_get wan)
interface6=$(config_get wan6)
server=$(config_get server)
if [ "${server}" = "__UNDEFINED__" ]; then
logger "Configure target LAN server in /etc/get_ipv6.conf"
exit 1
fi
#echo ${server}
address=$(ifstatus ${interface} | jsonfilter -e '@["ipv4-address"][0].address')
prefix=$(ifstatus ${interface6} | jsonfilter -e '@["ipv6-prefix"][0].assigned["lan"].address')
#echo ${prefix}
ip=$(nslookup ${server} | grep ${prefix} | cut -d " " -f 3)
echo ${address},${ip}
}
main
The script reads the prefix, then uses it to filter the correct public IPv6 from the list returned by nslookup for the parameterized ${server}. The IPv4 address is read normally on the wan interface.
I am not sure that I would be able to devise a fix, and my suggestion might not work.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with dynamic_dns_updater.sh and trace how use_ipv6, lookup_host, custom scripts, and the myip parameter are assembled. Reproduce the dyn.com behavior described in the issue, including simultaneous A and AAAA updates. Done means both records can be updated together without either record being deleted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, shell
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100