fix(h4): disable the unconfigured dnsmasq listening on both LAN addresses (2.14) - #572
Merged
Conversation
…sses (2.14) Found while establishing which interface the H4 should source LAN traffic from -- a question with nothing to do with DNS. dnsmasq was bound to 192.168.1.156:53 and 192.168.1.160:53 on a host that is not in the dns inventory group, is not in lab_dns_servers, and is not documented as serving DNS. Third time in two days that 'nothing in the repo references it' was false about the running system, after the writable Docker socket and the H4's own .156 address. Not a fifth lab resolver: the entire config is bind-interfaces, from /etc/dnsmasq.d/ubuntu-fan, an Ubuntu default nobody wrote. No host-record, no address=, no local=, no server=. It forwarded to systemd-resolved, which forwards to the real resolvers -- a redundant caching hop. And nothing had ever used it. SIGUSR1 makes dnsmasq dump counters to the journal without disrupting anything: queries forwarded 0, answered locally 0, authoritative zones 0, 0/0 cache insertions, over 5 days 14 hours of uptime. Zero, not low -- a weekly consumer would have appeared. Same discipline 2.9 is waiting on for Vault: remove a listener because the service says nobody is talking to it, not because the repo is silent. Disables the unit, does not purge the package: dnsmasq-base is a dependency of other things, and libvirt spawns its own instances per virtual network rather than using this systemd unit. The play refuses to act if the counters are non-zero, verifies by checking what is still bound to :53 rather than trusting systemctl is-active, and confirms the H4 can still resolve api.lab.home.arpa afterwards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while establishing which interface the H4 should source LAN traffic from -- a question with nothing to do with DNS. dnsmasq was bound to 192.168.1.156:53 and 192.168.1.160:53 on a host that is not in the dns inventory group, is not in lab_dns_servers, and is not documented as serving DNS. Third time in two days that 'nothing in the repo references it' was false about the running system, after the writable Docker socket and the H4's own .156 address.
Not a fifth lab resolver: the entire config is bind-interfaces, from /etc/dnsmasq.d/ubuntu-fan, an Ubuntu default nobody wrote. No host-record, no address=, no local=, no server=. It forwarded to systemd-resolved, which forwards to the real resolvers -- a redundant caching hop.
And nothing had ever used it. SIGUSR1 makes dnsmasq dump counters to the journal without disrupting anything: queries forwarded 0, answered locally 0, authoritative zones 0, 0/0 cache insertions, over 5 days 14 hours of uptime. Zero, not low -- a weekly consumer would have appeared. Same discipline 2.9 is waiting on for Vault: remove a listener because the service says nobody is talking to it, not because the repo is silent.
Disables the unit, does not purge the package: dnsmasq-base is a dependency of other things, and libvirt spawns its own instances per virtual network rather than using this systemd unit. The play refuses to act if the counters are non-zero, verifies by checking what is still bound to :53 rather than trusting systemctl is-active, and confirms the H4 can still resolve api.lab.home.arpa afterwards.