Bug 1999334
| Summary: | bind does not listen on all addresses over TCP when listen-on/listen-on-v6 has specific IPs or any listed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bojan Smojver <bojan> | ||||
| Component: | bind | Assignee: | Petr Menšík <pemensik> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 34 | CC: | aegorenk, anon.amish, dns-sig, mruprich, msehnout, pavel, pemensik, pspacek, vonsch, zdohnal | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | bind-9.16.21-1.fc35 bind-9.16.21-1.fc34 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1999691 (view as bug list) | Environment: | |||||
| Last Closed: | 2021-09-27 01:22:27 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1999691, 1999857 | ||||||
| Attachments: |
|
||||||
|
Description
Bojan Smojver
2021-08-30 22:47:48 UTC
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. |