Point production at a nameserver that resolves, and notify sooner

Two independent fixes to how the production zone is published.

The zone advertised NS pdns1.runonflux.io, in both its NS set and its SOA
MNAME. That name has no records of any type. What actually carries production
traffic is pdns.runonflux.io, which the parent zone delegates to and which is
steered geographically across the primary and both secondaries. Nothing is
broken today because resolvers follow the delegation and its glue, but the
zone's own NS set outranks that delegation under RFC 2181 5.4.1, so a resolver
that adopts it is left holding a nameserver name that resolves to nothing. The
staging zone already names the host it delegates to; production now does too.

Separately, the primary was never told how often to look for work. also-notify
says where a notification goes; xfr-cycle-interval says how soon one is sent at
all, and unset it defaults to sixty seconds. That delay is visible to clients
rather than internal, because the delegation is geographic and US and APAC
resolvers are answered by the secondaries: until a transfer lands, a name that
already exists on the primary is served by them from the zone wildcard, as a
CNAME to a proxy, carrying the zone's hour-long TTL. So a minute of staleness
can cost an hour of misdirection for whoever asked during it.

Measured on the staging pair before changing anything: a record written through
the gateway took 45 seconds to reach the secondary on the default, and under 4
when the write was followed by an explicit notify through the API. Ten seconds
puts the unassisted path close to the assisted one. The cost is a per-zone
serial scan every ten seconds on the primary, which scales with zone count and
is nothing at this one; secondaries do not poll harder as a result, since their
REFRESH governs that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: MorningLightMountain713

templates/pdns.conf.j2

@@ -87,6 +87,22 @@ allow-axfr-ips=127.0.0.1
 {% set env = 'staging' if DEPLOY_ENV == 'staging' else 'production' %}
 also-notify={{ powerdns[env].slave_ips | join(',') }}
 
+# How often the primary scans its own SOA serials to notice there is anything to
+# notify about. also-notify above only says WHERE a notification goes; this says
+# how quickly one is sent at all, and unset it defaults to 60s.
+#
+# That delay is client-visible, because the parent delegates geographically and
+# US and APAC clients are served by the secondaries. Until a transfer lands, a
+# name that already exists on the primary is answered by those secondaries from
+# the zone wildcard — a CNAME to a proxy, at the zone's hour-long TTL. Measured
+# at 45s on the default; a write followed by an explicit API notify converges in
+# under 4.
+#
+# The cost is a per-zone serial scan every 10s on the primary, which scales with
+# zone count and is negligible here. Secondaries do not poll more often as a
+# result; their REFRESH governs that.
+xfr-cycle-interval=10
+
 # Enable DNS updates for ACME challenges
 dnsupdate=yes
 allow-dnsupdate-from=127.0.0.1

vars.yaml

@@ -91,9 +91,13 @@ powerdns:
           routing_script: "app_routing.lua"
           routing_function: "appRouteCname"
           debug_function: "appRouteDebug"
-    soa_nameserver: "pdns1.runonflux.io."
+    # The name the parent zone delegates to, and the only one of ours that
+    # resolves. pdns1.runonflux.io has no records of any type, so a resolver that
+    # took the zone's own NS set — which outranks the delegation under RFC 2181
+    # §5.4.1 — would be left with no reachable nameserver for the zone.
+    soa_nameserver: "pdns.runonflux.io."
     soa_email: "hostmaster.runonflux.io."
-    nameservers: ["pdns1.runonflux.io."]
+    nameservers: ["pdns.runonflux.io."]
     master_ips: ["5.39.57.38"]
     slave_ips: ["5.161.203.77", "178.128.30.247"]
     # TSIG key for zone transfers (generate with: openssl rand -base64 48)