Track Y: data.quantecon.org DNS — the name points at an empty AWS load balancer

[mmcky]

data.quantecon.org is the final URL form for every dataset in this repo, and it is the last thing gating the interim → final cutover (#15). Today the name resolves to an AWS load balancer that serves nothing. This issue collects what is verifiable from outside and names the two things that need an answer from whoever holds the AWS account.

Opened separately from the data migration because it is the only piece of this programme with external lead time — no amount of dataset work moves it, and it should be in flight while the migrations proceed rather than discovered as a blocker at the end.

Verified state (2026-08-06)

data.quantecon.org is a bare A record to 52.64.86.66. There is no CNAME and no AAAA.

What answers there is an AWS Elastic Load Balancer, and it has no healthy targets behind it:

Probe	Result
http://data.quantecon.org/	301 → https://data.quantecon.org:443/, Server: awselb/2.0
https://data.quantecon.org/	503, server: awselb/2.0
TLS handshake	fails — no certificate valid for this name
Same IP with SNI quantecon.org	503
Same IP with SNI api.quantecon.org	503

A 503 from an ELB on every hostname means the listener has no healthy backend registered. The service this fronted is already gone; what remains is the load balancer itself, still resolving and still billing. That materially de-risks the decommission — the question is not "is this service still in use", it is "why is an empty ELB still in DNS".

The record is also fragile on its own terms. ELB IP addresses are not stable — AWS reassigns them. Pinning a bare A record at one is a configuration that can break without anyone touching it, independent of this migration.

Target configuration

quantecon.org is on Route 53 (ns-38.awsdns-04.com and three siblings), and the pattern for QuantEcon Pages subdomains is already well established:

Name	Current record
www.quantecon.org	CNAME → quantecon.github.io
python.quantecon.org	CNAME → quantecon.github.io
intro.quantecon.org	CNAME → quantecon.github.io
quantecon.org (apex)	the four Pages A records, 185.199.108–111.153

So the change is the same one made three times already: replace the A record with CNAME data.quantecon.org → quantecon.github.io, then set the custom domain on this repo so Pages provisions a certificate and enforces HTTPS.

One deployment detail specific to this repo: Pages here is deployed from Actions (actions/deploy-pages), not from a branch. Setting the custom domain in repo settings persists it, but if the setting is ever lost the artifact needs a CNAME file at its root — worth adding to .github/workflows/audit-dashboard.yml's "Assemble the Pages tree" step at the same time so the two cannot drift.

What needs an answer

1. Who owns the AWS account holding this ELB, and can it be decommissioned? The evidence says it is serving nothing, but that should be confirmed against the account rather than inferred from 503s.
2. Does anything else still point at 52.64.86.66? Other subdomains, non-HTTP traffic, or hard-coded references outside DNS. The SNI probes above suggest the ELB is a general catch-all rather than data-specific, so it may be fronting more than one retired name.

Neither question blocks the data migration. Both block #15.

What this does not block

Worth stating plainly, because the roadmap has assumed otherwise: the CORS requirement is already met and does not wait on this. quantecon.github.io/data-lectures/lectures/lingcod_msy_recovery.csv returns access-control-allow-origin: * today, so pyodide and JupyterLite fetches work against the current host (QuantEcon/meta#143). Interim URLs are also fully functional — every repointed lecture reads github.com/QuantEcon/data-lectures/raw/main/lectures/… and builds green.

So this is a tidiness and stability milestone, not a functional blocker. The cost of it staying open is that every repointed lecture carries a URL we intend to change once, which is exactly what #15 exists to sweep.

Sequence once the questions are answered

1. Confirm the ELB is decommissionable; identify anything else depending on it
2. Route 53: A 52.64.86.66 → CNAME quantecon.github.io
3. Repo settings: set the custom domain, wait for the Pages certificate, enable "Enforce HTTPS"
4. Add the CNAME file to the Pages artifact so the setting cannot silently drift
5. Re-verify access-control-allow-origin: * on the new host
6. Run the Phase 4 cutover: swap interim raw URLs → data.quantecon.org/lectures #15 sweep: interim → https://data.quantecon.org/lectures/<file>, one PR per consumer repo, then repointed → final in migration.yml
7. Decommission the ELB

Track Y in PLAN.md. Gates #15. Part of #8. Related: QuantEcon/meta#143, QuantEcon/meta#336.

[mmcky]

Two additions from the 2026-08-06 validation pass (#45), one observation and one acceptance criterion.

The dead box now fronts a third-party certificate. As of 2026-08-06 the name still resolves to 52.64.86.66 (AWS Sydney; rDNS still answers data.quantecon.org), http redirects 301 → https, and behind TLS it is awselb/2.0 returning 503 — consistent with what this issue records. What's new: the load balancer now presents a certificate for *.dev.cloud.payok.com.au, so a browser hits a certificate error before ever seeing the 503. If that ELB or its IP is no longer in a QuantEcon-controlled AWS account, the A record is dangling on someone else's infrastructure — worth confirming ownership when the decommission question is investigated, since a dangling record on a reassignable address is a takeover-shaped exposure, not just a dead page.

Acceptance criterion for the cutover: CORS. lecture-wasm executes code cells in the reader's browser, so its data reads only work against hosts that serve access-control-allow-origin: * — the reason behind #46 and repoint rule 5. When data.quantecon.org is repointed to its future home, that host must send access-control-allow-origin: * on data responses (GitHub Pages does), and the check belongs in the cutover checklist on #15 before any wasm consumer swaps to the final URL. One-line test from any quantecon.github.io page console: fetch('https://data.quantecon.org/lectures/<file>') must resolve, not reject.

[mmcky]

The AWS-ownership question is now tracked org-side as QuantEcon/meta#353 — it carries the full observed state (third-party cert, empty ELB, rDNS) and the decision fork: decommission if QuantEcon-owned, remove the A record promptly if not. This issue stays the data-lectures-side track for the eventual Pages repoint.

[mmcky]

Adding a hard acceptance criterion to this work: whatever ends up serving data.quantecon.org must send access-control-allow-origin: * on data responses, or lecture-wasm cannot cut over to it. lecture-wasm executes its code cells in the reader's browser (JupyterLite/Pyodide; six lectures call pyodide_http.patch_all(), which routes pandas URL reads through XMLHttpRequest), so every data read is a cross-origin fetch subject to CORS. This is not a nice-to-have for the cutover in #15 — a host that resolves, serves the right bytes and passes every CI check will still fail silently for every wasm reader if the header is missing.

The evidence is from #46, and the header behaviour is re-measurable today with curl -I:

URL form	status	access-control-allow-origin	in-browser
github.com/QuantEcon/data-lectures/raw/main/lectures/<file>	302 → raw host	empty	fails — the CORS check runs on the redirect response, before the hop is followed
raw.githubusercontent.com/QuantEcon/data-lectures/main/lectures/<file>	200	*	works
quantecon.github.io/data-lectures/lectures/<file>	200	*	works

That first row is the second-order requirement, and it is the one a CDN or object-storage fronting is most likely to get wrong: the criterion applies to redirects, not just to the final response. If data.quantecon.org 302s to storage — an S3/R2 bucket, a Pages URL, anything — the redirect response itself must carry access-control-allow-origin: *. GitHub's own github.com/*/raw/ form is the worked example of getting this wrong: it redirects to a host that is perfectly CORS-clean, and is still unusable from a browser because the 302 sends an empty header.

This is not testable from CI in the usual way — the failure exists only inside a reader's browser, which is why nothing caught #46 until an independent validation run did. The check is a headless-browser fetch executed from a page on the site's own origin: load any https://quantecon.github.io/lecture-wasm/… page and evaluate fetch('https://data.quantecon.org/lectures/lingcod_msy_recovery.csv').then(r => r.status). It must resolve, not reject; a rejection with "Failed to fetch" and no status is the CORS failure. Worth running once against the interim host before cutover so the pass/fail is a comparison, not a first observation.