data.quantecon.org: DNS points at an AWS load balancer now serving a third-party certificate — confirm ownership

[mmcky]

data.quantecon.org needs someone with AWS console access to establish who owns the infrastructure its DNS points at, because the answer decides between "decommission at leisure" and "remove the DNS record promptly".

Observed state (2026-08-06, all independently verified)

Probe	Result
DNS	data.quantecon.org → A record 52.64.86.66 (AWS ap-southeast-2, Sydney)
Reverse DNS	52.64.86.66 → data.quantecon.org (rDNS is set by whoever holds the address, so this was configured deliberately at some point)
http://	301 → https://data.quantecon.org:443/
https://	TLS presents a certificate for *.dev.cloud.payok.com.au — a third party — so browsers fail with a certificate error before seeing any content
Behind the cert (curl -k)	server: awselb/2.0 returning 503 Service Temporarily Unavailable — an AWS load balancer with no healthy targets

So the name is dead as a service either way. The open question is whose load balancer is answering.

Why ownership is the deciding question

If the ELB/EIP is still in a QuantEcon-controlled AWS account, this is leftover infrastructure (the old NestJS box, per earlier notes): the third-party certificate would mean the LB is shared or its default listener certificate was changed, and the cleanup is to decommission it and release the address whenever convenient.

If it is not — if the address was released at some point and reallocated — then our A record is dangling on infrastructure someone else controls. A dangling record on a reassignable address is a takeover-shaped exposure, not just a dead page: whoever holds the address can serve arbitrary content under data.quantecon.org, including obtaining a valid certificate for it via HTTP-01 validation. In that case the A record should be removed promptly, independent of any future plans for the name.

The certificate observation is what raises the question: a QuantEcon-owned LB has no reason to present *.dev.cloud.payok.com.au.

What resolving this unblocks

data-lectures Phase 4 plans to serve the canonical lecture datasets at https://data.quantecon.org/lectures/<file> via GitHub Pages (custom domain), tracked in QuantEcon/data-lectures#37 (the DNS track) with the cutover runbook in QuantEcon/data-lectures#15. That work is gated on this DNS decision: the record needs to be confirmed decommissionable, then repointed to GitHub Pages. One acceptance criterion already recorded there: the new hosting must serve access-control-allow-origin: *, because lecture-wasm executes code cells in the reader's browser (data-lectures repoint rule 5; GitHub Pages satisfies this).

Asks

1. Someone with access to the relevant AWS account(s): confirm whether ELB/EIP 52.64.86.66 is QuantEcon-controlled.
2. If ours: decommission the LB and release the address (or document why it stays); then Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10 data-lectures#37 can proceed with the repoint to GitHub Pages.
3. If not ours: remove the data.quantecon.org A record immediately, and note the removal on Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10 data-lectures#37 so the Pages CNAME work starts from a clean slate.

[mmcky]

Resolved on the exposure side, 2026-08-06: @mmcky deleted the data.quantecon.org A record in Route53. Verified against the authoritative nameserver (ns-1102.awsdns-09.org): the name now returns no A record (SOA-only answer), and public resolvers have already dropped it — so nothing points at 52.64.86.66 any more and the dangling-record/takeover concern is closed, independent of who owns the load balancer.

What remains of the original asks, both non-urgent now:

• Ask 1 (ELB ownership) is downgraded from security question to cost/tidiness: if 52.64.86.66 and the ELB behind it are in a QuantEcon AWS account, they are unreferenced billable resources that can be released; the third-party certificate suggests they may not be ours at all, in which case there is nothing left to do.
• Phase 4 (Track Y (deferred): data.quantecon.org DNS + custom domain — retired in favor of qeld (D11); reopenable, NXDOMAIN as of 2026-08-10 data-lectures#37) now starts from a clean slate: when the GitHub Pages hosting is ready, the name gets re-created as an ALIAS/CNAME to Pages, with the access-control-allow-origin: * acceptance criterion already recorded there.

[mmcky]

@DrDrij can we do a review to see if we are running any Load Balancers on AWS?

[mmcky]

Status correction, 2026-08-10: data.quantecon.org is now NXDOMAIN, with the authoritative flag set, at quantecon.org's own nameserver — the stale A record is gone, confirming the deletion recorded here. The QuantEcon/data-lectures Pages cname is also null, so nothing currently claims the name from either side.

That closes the security framing of this issue: there is no dangling record and no third-party cert being presented. What remains is cost-only — releasing the load balancer and any EIP, if the AWS account is QuantEcon's.

It also unblocks Track Y of the datasets migration, which had been recorded as waiting on "an external infra answer". It is not waiting on anything external any more: creating the record and setting the custom domain are both actions QuantEcon controls. Tracked at QuantEcon/data-lectures#15.