The resolver declares both protocols it answers on

It declared udp/53 only. The daemon listens on tcp/53 as well, and a resolver is asked over tcp whenever an answer will not fit in a datagram — so on every converged machine that port is closed while the service reports itself healthy and the manifest reads as though the resolver were fully declared. The same fault as issue 136 in miniature: the declaration covers part of what the service does, and the gap is silent because nothing compares the two.
Merge pull request 'sshd: the daemon it owns starts at boot' (#136 ) from fix/sshd-declares-the-daemon-it-owns into main
2026-09-28 23:53:03 +02:00 · 2026-09-28 19:43:29 +00:00 · 2026-09-28 21:43:27 +02:00 · 2026-09-28 18:48:26 +00:00 · 2026-09-28 20:48:24 +02:00 · 2026-09-28 18:45:34 +00:00
3 changed files with 9 additions and 1 deletions
@@ -27,6 +27,13 @@
      "from": "mesh",
      "why": "every name for this machine and what it runs \u2014 the mesh's own answered here, the rest forwarded",
      "fixed": true
+    },
+    {
+      "port": 53,
+      "protocol": "tcp",
+      "from": "mesh",
+      "why": "the same names over tcp, which a resolver answers on as well and is asked for whenever an answer will not fit in a datagram. Declared because the daemon serves it: a declaration that covers one of the two protocols its own service listens on leaves the other closed while everything reports success",
+      "fixed": true
    }
  ],
  "resources": [
@@ -33,7 +33,7 @@
      "type": "file",
      "path": "/etc/fail2ban/jail.local",
      "mode": "0644",
-      "content": "[INCLUDES]\n\nbefore = paths-arch.conf\n\n[DEFAULT]\n\n# Never act on the machine itself or on a tunnel peer: the mesh's private range is\n# ${machine:mesh-range}, named here rather than written as a value the module cannot\n# know (novox/hq ADR 0112). Without this, fail2ban could ban the mesh's own nodes.\nignoreip = 127.0.0.1/8 ::1 ${machine:mesh-range}\n\nbantime  = 10m\nfindtime = 10m\nmaxretry = 5\n\nbanaction = ufw\nbanaction_allports = iptables-allports\n\n[sshd]\nenabled = true\nport    = ssh\nlogpath = %(sshd_log)s\nbackend = %(sshd_backend)s\n"
+      "content": "[INCLUDES]\n\nbefore = paths-arch.conf\n\n[DEFAULT]\n\n# Never act on the machine itself or on a tunnel peer: the mesh's private range is\n# ${machine:mesh-range}, named here rather than written as a value the module cannot\n# know (novox/hq ADR 0112). Without this, fail2ban could ban the mesh's own nodes.\nignoreip = 127.0.0.1/8 ::1 ${machine:mesh-range}\n\nbantime  = 10m\nfindtime = 10m\nmaxretry = 5\n\n# Ban through iptables, not through a firewall front-end the machine may not have. ufw is\n# installed on two of this mesh's machines and absent on the other two, and fail2ban finds out\n# only at ban time: the service reports healthy, the jail counts the attempt, the ban command\n# exits 127, and nothing is blocked. Proven on 2026-09-28 -- 'ufw: command not found' on a\n# machine the mesh reported as protected.\n#\n# The action below is this module's own, already used by the recidive jail on every machine\n# here, and it bans in DOCKER-USER as well as INPUT, so a container's published port is\n# covered too.\nbanaction = iptables-allports-dualchain\nbanaction_allports = iptables-allports-dualchain\n\n[sshd]\nenabled = true\nport    = ssh\nlogpath = %(sshd_log)s\nbackend = %(sshd_backend)s\n"
    },
    {
      "id": "jail-sshd",
@@ -31,6 +31,7 @@
      "type": "service",
      "unit": "sshd.service",
      "state": "running",
+      "boot": "enabled",
      "restart-on": [
        "config"
      ]
Author	SHA1	Message	Date
jschoubben	acedc5d9d9	The resolver declares both protocols it answers on It declared udp/53 only. The daemon listens on tcp/53 as well, and a resolver is asked over tcp whenever an answer will not fit in a datagram — so on every converged machine that port is closed while the service reports itself healthy and the manifest reads as though the resolver were fully declared. The same fault as issue 136 in miniature: the declaration covers part of what the service does, and the gap is silent because nothing compares the two.	2026-09-28 23:53:03 +02:00
mesh-admin	521a8dd1e2	Merge pull request 'sshd: the daemon it owns starts at boot' (#136 ) from fix/sshd-declares-the-daemon-it-owns into main	2026-09-28 19:43:29 +00:00
jschoubben	e145e2236c	sshd: the daemon it owns starts at boot The module said the service must be running and nothing about boot, so the machine's own way back in was enabled only because something before the mesh had enabled it. All four machines happen to be enabled today; none of them is enabled because the mesh says so, and a machine adopted tomorrow would run ssh until its first reboot. Not `state: running` alone for the same reason the module exists: this is the one daemon whose absence cannot be fixed remotely.	2026-09-28 21:43:27 +02:00
mesh-admin	4d7e37e319	Merge pull request 'fail2ban bans through an action every machine has' (#135 ) from fix/fail2ban-bans-through-what-every-machine-has into main	2026-09-28 18:48:26 +00:00
jschoubben	026421fd6e	fail2ban: ban through an action every machine has jail.local named ufw as the ban action. Two machines on this mesh have no ufw, and fail2ban does not check: it starts, the jail reads the log, counts the attempts, runs the ban command, gets 127 -- 'ufw: command not found' -- and logs an error nobody reads. The service is active, the mesh reports the module applied, and the machine is not protected. Proven by banning a documentation address on such a machine today. The replacement is this module's own dualchain action, already used by the recidive jail on all four machines, so it is not a new dependency. It bans in DOCKER-USER as well as INPUT, which ufw's action did not, and it bans all ports, which ufw's action did.	2026-09-28 20:48:24 +02:00
mesh-admin	af89bb11ff	Merge pull request 'fail2ban declares the log its own recidive jail reads' (#134 ) from fix/fail2ban-declares-the-log-its-own-jail-reads into main	2026-09-28 18:45:34 +00:00