You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clients fall back to individual CDN nodes when the geo-routed name is unusable,
so that list cannot be discovered through the CDN - it would be circular. Today
it is a compile-time constant in a pinned wheel (flux-bootstrap
data_structures.py DIRECT_CDN_URLS, duplicated twice more in cdn_manager.py) and
in flux_iso_updater's backup_hosts. Retiring a node therefore needs a client
release rolled out to every Flux node, which is why cdn-2.runonflux.io - shut
down in July, its address since re-leased to another customer - is still in the
failover set of two separate consumers.
DNS is the right channel for it. It is a different failure domain from HTTP,
which is what a fallback path needs, and it is not a new dependency: the entries
in those hardcoded lists are already hostnames, so the client cannot use them
without a resolver either. Publishing the set here rather than the members is
strictly better than the status quo. It also holds up in the failure that
matters - if geo routing hands out a bad answer for cdn.runonflux.io, a plain
non-geo lookup against the same authoritative servers still resolves.
SRV rather than several A records at a well-known name, because A returns bare
addresses and connecting by IP defeats certificate verification - the very check
that would have caught cdn-2's address changing hands. An SRV target is a
hostname, so the client resolves it and verifies normally.
In the zone rather than in Cloudflare because records there are managed by
nothing, which is precisely how cdn-2's A record survived being cleaned out of
everywhere else. Here the reconcile owns them, templated from geo_regions - the
same source of truth that already drives geo routing and the _health records -
so retiring a region updates routing and the node list together and neither can
rot. Only geo zones have regions, so only they advertise a list.
One rrset per zone holding every target: a changed set is a single REPLACE, an
emptied one a single DELETE bound to that one name.
Mutation testing found a real gap while writing this. Comparing the records
within an rrset unsorted passed the whole suite, because every fixture happened
to be in sorted order already - PowerDNS promises no ordering, so that would have
rewritten the rrset on every run. Both SRV and the apex NS set now have a test
with deliberately unsorted input, and each fails if its sort is removed. Note
"pdns-b." sorts before "pdns." there; listing them the other way round proves
nothing.
The first production run will create the SRV rrset and change nothing else,
which is asserted directly rather than left to be discovered on deploy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments