DNS server does not listen on IPv6 after a reboot
I have two newly created 20.04 instances on AWS (Amazon Web Services). One is of type t2, the other of type t3.
These instances have both IPv4 and IPv6 configured. As you probably know, these addresses are not static from the OS point of view, but are obtained through AWS' DHCP. However, such an instance always gets the same IPv4 and IPv6 addresses.
Both instances have the same problem.
I installed and configured a DNS server (bind 9.16.1). The DNS server starts automatically after a reboot, but does not seem to bind to the IPv6 address (it uses only the "link local address").
For example, a netstat after reboot gives:
# netstat -natpu | grep /named
tcp 0 0 172.31.xx.xxx:53 0.0.0.0:* LISTEN 581/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 581/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 581/named
tcp6 0 0 fe80::xxx:xxxx:xxxx::53 :::* LISTEN 581/named
tcp6 0 0 ::1:53 :::* LISTEN 581/named
tcp6 0 0 ::1:953 :::* LISTEN 581/named
udp 0 0 172.31.xx.xxx:53 0.0.0.0:* 581/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 581/named
udp6 0 0 ::1:53 :::* 581/named
udp6 0 0 fe80::xxx:xxxx:xxxx::53 :::* 581/named So, I have to restart the server:
# systemctl restart named
# netstat -natpu | grep /named
tcp 0 0 172.31.xx.xxx:53 0.0.0.0:* LISTEN 31425/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 31425/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 31425/named
tcp6 0 0 fe80::xxx:xxxx:xxxx::53 :::* LISTEN 31425/named
tcp6 0 0 2600:xxxx:xxx:xxxx:x:53 :::* LISTEN 31425/named
tcp6 0 0 ::1:53 :::* LISTEN 31425/named
tcp6 0 0 ::1:953 :::* LISTEN 31425/named
udp 0 0 172.31.xx.xxx:53 0.0.0.0:* 31425/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 31425/named
udp6 0 0 ::1:53 :::* 31425/named
udp6 0 0 2600:xxxx:xxx:xxxx:x:53 :::* 31425/named
udp6 0 0 fe80::xxx:xxxx:xxxx::53 :::* 31425/named This problem does not seem to be network interface-related, because t2 and t3 instances use very different type of network interfaces and the previous version of Ubuntu (18.04) did not have such a problem.
My guess is that the DNS server is started very early (before global IPv6 is obtained from DHCP and assigned to the network interface).
Note: This issue happens also when some packages are installed (I haven't determined yet which ones) and as a result some triggers are processed.
How can I delay the start of DNS service after the proper IPv6 address is obtained from DHCP? Or is there any other solution you would suggest?
Currently, my solution is putting something like this to the end of my "general system startup script":
...
sleep 10 # or more
systemctl restart named.service 2>&1
...2 Answers
I was having the same issue, and attempted to modify the named "bind" scripts in 20.04 LTS to no avail. I then changed my thinking, and then found the solution to delay the named service startup via the system and found an article via ASK.
Not sure why the ipv6 subsystems and network interfaces take so long to initialize.
The solution I am using is I added a line to the /lib/systemd/system/named.service file in the service stanza like this. "Inserted the line just under the stanza heading".
[Service]
ExecStartPre=-/bin/sleep 10
This seems to be the best way to solve this issue, so you don't have to muck with the startup scripts as those will change as packages get updated over time.
I am running some Acer laptops with the latest I5 gen 9 processors, on top of an SSD drive and it boots so fast, I also have other race conditions with peripheral hardware interfaces and firewall startup scripts that can be solved the same way.
Hope this helps!
IPv6 takes a while to load due to Duplicate Address Detection (DAD), during which time the addresses are set to a 'tentative' mode and aren't available for use even though one is assigned. This state persists until DAD confirms the machine is the only user of that IPv6 address. This article goes into more detail:
A key piece of the solution is to disable DAD. From the article:
To disable DAD, you need to write 0 to /proc/sys/net/ipv6/conf/ethX/accept_dad, where ethX is the interface, before you configure the interface. In Debian, I accomplish this using a pre-up directive on the interface stanza, like this:
iface eth0 inet6 static address 3ffe:ffff::4a:5000 netmask 64 gateway fe80::1 pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_dad
Personally, I just put net.ipv6.conf.eth0.accept_dad=0 in my sysctl.conf to make the whole problem go away, since I can manually confirm that the address will be unique.
P.S: You could also look into "Optimistic DAD" if your kernel has support for it. I haven't tried it though, so YMMV.
