Repository navigation
Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10 #37
Description
Activity
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 answersdata.quantecon.org), http redirects 301 → https, and behind TLS it isawselb/2.0returning 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-wasmexecutes code cells in the reader's browser, so its data reads only work against hosts that serveaccess-control-allow-origin: *— the reason behind #46 and repoint rule 5. Whendata.quantecon.orgis repointed to its future home, that host must sendaccess-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 anyquantecon.github.iopage console:fetch('https://data.quantecon.org/lectures/<file>')must resolve, not reject.- added a commit that references this issue
on Aug 6, 2026 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.
Adding a hard acceptance criterion to this work: whatever ends up serving
data.quantecon.orgmust sendaccess-control-allow-origin: *on data responses, orlecture-wasmcannot cut over to it.lecture-wasmexecutes its code cells in the reader's browser (JupyterLite/Pyodide; six lectures callpyodide_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-originin-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.org302s to storage — an S3/R2 bucket, a Pages URL, anything — the redirect response itself must carryaccess-control-allow-origin: *. GitHub's owngithub.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 evaluatefetch('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.Deferred indefinitely, 2026-08-12 — the stable interface is
qeld, not a branded hostDecision recorded in PLAN-QELD-PACKAGE.md §2.2 (D11) via #76: the programme invests in the
qeldconsumer package (#65) rather than establishingdata.quantecon.org. The package delivers everything the domain would have — one constant interface point that survives backend rework — plus tidier lectures (qeld.url('<file>')with the URL still oneprint(url)away) andinfo()metadata at the call site, without the forever-promise of a branded public host. That also means #35's licensing review stops being a looming gate: it binds only if a public host is someday established after all.This issue stays open as the deferred tracker, not as scheduled work. It is deferred-not-dead by construction: D11 pins qeld's base URL to the raw repo forms (never
quantecon.github.io, whose form would start 301-redirecting the moment a custom domain lands — re-creating the redirect-CORS failure for shipped wheels). Raw URLs are untouched by Pages domain changes, so reviving this issue at any future point is one DNS record, one repo setting, and one minor qeld release.Two updates to this issue's body while recording this:
The verified state is stale. As of 2026-08-10,
data.quantecon.orgis NXDOMAIN atquantecon.org's own authoritative nameserver and the repo's Pagescnameis null — the stale A record and the ELB behind52.64.86.66are both gone. So the decommission questions this issue asked are answered by deletion, and the dangling-record / third-party-certificate exposure flagged in the 2026-08-06 comment is also gone.The CORS acceptance criterion outlives the cutover. Any host
lecture-wasmever reads from must serveaccess-control-allow-origin: *on a direct 200 with no redirect hop — restated host-generically in PLAN.md rule 5, and it binds in full if this is ever revisited.#15 (the interim→final URL sweep) is superseded by qeld adoption — see the comment there.
- added a commit that references this issue
on Aug 12, 2026 - changed the title
[-]Track Y: data.quantecon.org DNS — the name points at an empty AWS load balancer[/-][+]Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10[/+]on Aug 12, 2026
data.quantecon.orgis 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.orgis a bare A record to52.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:
http://data.quantecon.org/301→https://data.quantecon.org:443/,Server: awselb/2.0https://data.quantecon.org/503,server: awselb/2.0quantecon.org503api.quantecon.org503A 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.orgis on Route 53 (ns-38.awsdns-04.comand three siblings), and the pattern for QuantEcon Pages subdomains is already well established:www.quantecon.orgCNAME → quantecon.github.iopython.quantecon.orgCNAME → quantecon.github.iointro.quantecon.orgCNAME → quantecon.github.ioquantecon.org(apex)185.199.108–111.153So 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 aCNAMEfile 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
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.csvreturnsaccess-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 readsgithub.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
A 52.64.86.66→CNAME quantecon.github.ioCNAMEfile to the Pages artifact so the setting cannot silently driftaccess-control-allow-origin: *on the new hosthttps://data.quantecon.org/lectures/<file>, one PR per consumer repo, thenrepointed→finalinmigration.ymlTrack Y in
PLAN.md. Gates #15. Part of #8. Related: QuantEcon/meta#143, QuantEcon/meta#336.