Slipgate diagnostics reports false positive port 53 conflict

[shlyahten]

slipgate diagnostics reports port 53 conflict with systemd-resolved despite slipgate already listening on :53

Version: slipgate v1.6.4 (166dca9)

---

Description

Running slipgate diagnostics produces 1 failed check:

[-] systemd-resolved stub    still active — port 53 conflict

However, ss and netstat confirm that slipgate itself is already successfully listening on port 53/udp, and no actual conflict exists at the socket level:

udp   UNCONN 0      0      *:53    *:*    users:(("slipgate",pid=364952,fd=4))

The diagnostic check appears to be a false positive: it detects that systemd-resolved stub resolver has not been explicitly disabled, but does not verify whether port 53 is actually occupied by another process before reporting a failure.

---

Steps to reproduce

1. Install and configure slipgate with a tunnel (e.g. slipstream)
2. Ensure systemd-resolved stub is present in the system but port 53 is already bound by slipgate
3. Run slipgate diagnostics

[d010b]

Why does this message appear?

Looking at the isResolvedStubDisabled() function in system_diag.go:

go
func isResolvedStubDisabled() bool {
data, err := os.ReadFile("/etc/systemd/resolved.conf.d/slipgate-no-stub.conf")
if err != nil {
return false
}
return strings.Contains(string(data), "DNSStubListener=no")
}
The diagnostic reports that the stub listener is still active when either:

/etc/systemd/resolved.conf.d/slipgate-no-stub.conf does not exist, or

The file exists but does not contain DNSStubListener=no