Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10

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:

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:

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 #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.

Start by reviewing the verified DNS and ELB state, the Route 53 records, and .github/workflows/audit-dashboard.yml's Pages artifact assembly. Confirm ownership and dependencies for 52.64.86.66 before changing the record, then configure the custom domain and CNAME artifact; done means HTTPS works, CORS remains available, and the ELB can be decommissioned.