Description of problem: On boot, named will not listen on TCP sockets of all specified (or any) IP addresses. This appears to be an ordering problem during startup. When service is restarted by hand, it starts listening on TCP too. Version-Release number of selected component (if applicable): bind-9.16.20-3.fc34.x86_64 How reproducible: Always. Steps to Reproduce: 1. Configure specific IPs in listen-on/listen-on-v6 directives or any. 2. Boot machine with named-chroot service enabled. 3. Named only listening on all IPs over UDP. Actual results: Listens on all addresses over UDP only. Expected results: Should listen on TCP too, not just on the loopback address. Additional info: I tried adding: ----- [Unit] Wants=network-online.target After=network-online.target ----- in /etc/systemd/system/named-chroot.service.d/named-chroot.conf file and that did help.
I think this is related to upstream issue #2852, please continue there.
Indeed, Petr seems to be correct, it looks related to upstream issue linked. Can you please check journalctl would contain additionally listening? journalctl -xeu named-chroot | grep 'additionally listening' I were unable to reproduce this issue on my test machine. My named listens on all IPs with both UDP and TCP, checked by: lsof -n -p $(pidof named) | grep :domain Is this issue reproducible on every reboot on your system? Would "rndc scan" command fix missing listeners?
Created attachment 1819450 [details] reproducer.sh I were able to reproduce this issue with reproducer script provided on upstream. It seems reliable when named starts and passes scanning of addresses in correct place.
(In reply to Petr Menšík from comment #2) > Can you please check journalctl would contain additionally listening? > > journalctl -xeu named-chroot | grep 'additionally listening' No matches. > I were unable to reproduce this issue on my test machine. My named listens > on all IPs with both UDP and TCP, checked by: > lsof -n -p $(pidof named) | grep :domain > > Is this issue reproducible on every reboot on your system? Yes, it was. I actually only discovered this because renewal of Let's Encrypt cert failed on this system, due to DNS errors. It took me a while to realise that Let's Encrypt's ACME uses TCP for DNS. So, my named-chroot was limping along using UDP for everyone and TCP on localhost for a while, which made it sort of semi-functional. > Would "rndc scan" command fix missing listeners? I have not tried that. But, after I ordered named-chroot after network-online.target, the problem went away. Or at least it did across a couple of reboots.
Perhaps it is no longer visible at the end of logs, because you have found network-online.target workaround. Could you please try just journalctl -u named-chroot | grep 'additionally listening' and check, whether they were logged at time it did not listen on TCP properly? In case those logs are not already cleaned, of course. Do you know the date, when Let's Encrypt renewal occurred? Can you please check logs of named-chroot on that date? Does grep 'additionally listening' -r /var/named/data/named.run* contain them at least?
First time this failed was on 30 Aug 2021 at 00:01 AEST (i.e. +10 TZ). My journal goes back to April. There is also nothing in that other location. My named-chroot does run from /var/named, but my named.conf is very custom. So, that is the likely reason I cannot find these entries.
FEDORA-2021-aebf5de259 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aebf5de259
FEDORA-2021-3215da7cce has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3215da7cce
FEDORA-2021-3215da7cce has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3215da7cce` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3215da7cce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-aebf5de259 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-aebf5de259` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-aebf5de259 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3215da7cce has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Unfortunately, this has not been fixed. I removed my workaround and after today's reboot, named is only listening on localhost again.
# netstat -tlnp | grep :53 tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 876/named tcp6 0 0 ::1:53 :::* LISTEN 876/named # grep listen /etc/named.conf listen-on { 127.0.0.1; <another-ip4>; }; listen-on-v6 { ::1/128; <another-ip6>; };
FEDORA-2021-aebf5de259 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.