CroneKorkN
6cc823613a
The slave's bw-managed zone files are rendered from the master's metadata at slave-apply time. Changing a record on the master only publishes once both bw apply runs are done. The left4me-integration session burned ~20 minutes assuming bw apply on htz.mails would propagate to ovh.secondary via bind's own AXFR; it doesn't, because bw verify measures the on-disk file, not the running zone. Frame as the workflow rule rather than the absolute "not AXFR" claim — the bundle does set type slave; in named.conf.local, but that's orthogonal to the practical apply-both rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| files | ||
| items.py | ||
| metadata.py | ||
| README.md | ||
bind
Authoritative DNS — primary plus optional bind/master_node slaves.
Applying changes needs both nodes
The slave's bw-managed zone files are rendered from the master's
metadata at slave-apply time (see bundles/bind/items.py:100). When
you change a record on the master (adding a letsencrypt/domains
entry, a new vhost, etc.), the change is only published once you
apply BOTH:
bw apply htz.mails # primary (where the source records live)
bw apply ovh.secondary # secondary (renders its own zone files)
Until both have been applied, bw verify ovh.secondary will show
stale zones and consumers that hit the secondary (Let's Encrypt's
secondary-region validators in particular) will see NXDOMAIN. Even
though the slave's named.conf.local declares type slave;, don't
rely on bind's own AXFR catching up — the bw-rendered file on disk
is what bw verify measures.
See also
bundles/bind-acme/— the in-house ACME-update receiver.bundles/letsencrypt/README.md— DNS-01 prerequisites and the negative-cache penalty (the most common operational consequence of forgetting to apply the secondary).