DNS Inventory & Cutover Runbook

Published

September 17, 2026

NoteStatus: executed 2026-09-28; now part of the migration record

The cutover this page planned is done; see Outcome below. The rest of the page is kept as written on the day, apart from corrections marked as such. Built from a Route53 hosted-zone export for bioconductor.org (166 records, reviewed 2026-09) plus a direct HTTPS probe of every resolvable hostname in it — not just the DNS target, but what each one actually serves today. Satisfies the M1 task “cutover runbook page (DNS, verification, rollback)” from the roadmap. The M1 task “decide www./secure. and satellite hostnames” is still open. Not yet walked with the core team — treat every status and finding below as the reviewer’s read, not a decision. Probes were run from the open internet with no VPN/internal access, so “no response” below means not reachable from outside, not necessarily dead.

Updated 2026-09-17: the apex mechanism is settled — the zone’s nameservers move to Cloudflare — and the migration plan below was added.

Updated 2026-09-28: steps 1 and 2 are done. The zone was copied to Cloudflare and verified. The registrar’s nameservers were switched to Cloudflare the same afternoon; the .org delegation showed the Cloudflare pair by 17:32 UTC.

Updated 2026-09-28, evening: step 3 is done. The apex and www records were switched to Proxied at about 20:09 UTC, and bioconductor.org has been served by the new edge since. CloudFront stays in place behind the unchanged CNAMEs as the rollback target. Record freeze until 2026-10-12: change no DNS record in either zone, or make every change identically in both. Proxy status, zone settings and firewall rules exist only in Cloudflare, so they’re exempt.

Outcome (2026-09-30)

  • Serving. bioconductor.org and www have been proxied through Cloudflare to the bioc-site Worker since about 20:09 UTC on 2026-09-28, and next.bioconductor.org is served by the same Worker. The zone went Active on Cloudflare’s nameservers at 17:29 UTC that day, and the .org delegation showed them by 17:32.
  • Acceptance. BiocManager::install() for 3.23 and 3.24 passed against bioconductor.org on 2026-09-28. Measured 2026-09-29, 16:00–18:00 UTC: about 4,400 requests a minute, no 5xx responses, 63% served from the edge cache.
  • Changes after the flip. A WAF rule blocks AS150436 and AS4229 on /talks/ (the crawler of 2026-09-28, bioc-edge#32); Browser Cache TTL is “Respect existing headers” (bioc-edge#38); 404s return the site’s 404 page since 2026-09-29 (bioc-edge#52).
  • Watching. bioc-edge’s daily health.yml has probed bioconductor.org since 2026-09-29, and parity.yml compares it with master.
  • Rollback. The Route53 zone and CloudFront are unchanged and remain the rollback target; the record freeze runs until 2026-10-12. The rollback steps in section 3 are written down but have not been rehearsed; that M1 item is still open on the roadmap.
  • Still open from this page. The www./secure./satellite hostnames decision, and the open questions at the end. Account ownership and billing are tracked on Cloudflare account migration.

What M1 actually changes

Two records carry the entire cutover:

Hostname Type Current target Note
bioconductor.org (apex) A, Route53 Alias d3hzwifbu1gvt4.cloudfront.net. The CloudFront distribution being retired
www.bioconductor.org A, Route53 Alias bioconductor.org. Aliases to the apex, not to CloudFront directly

Both are live and serve the production site (“Bioconductor - Home”) today. Everything else in the zone is satellite: conference sites, mailing-list infrastructure, build machines, DKIM keys. None of it needs to change for the site itself to move — it either already points off AWS, or points at AWS/Jetstream2 resources this cutover doesn’t touch.

The apex is the hard part

Route53 “Alias” records — the mechanism used for the apex today — only resolve to AWS resources (CloudFront, ELB, S3, another record in the same zone, etc.). They cannot target an arbitrary external host like bioc-dev.cancerdatasci.org, and a plain CNAME isn’t legal at a zone apex per the DNS spec. www.bioconductor.org doesn’t have this problem — it’s not the apex, so it can become a normal CNAME to the new edge once the zone is ready. Decision (2026-09-17): move the zone’s nameservers to Cloudflare. Cloudflare flattens a CNAME at the apex, so the apex can target the Worker directly, and AWS leaves the DNS path entirely. The domain registration stays at AWS; only the nameservers change.

Rejected: a thin CloudFront distribution as a pass-through, origin set to bioc-dev.cancerdatasci.org, with the Route53 Alias repointed at it. It moves no records, but keeps AWS in the request path indefinitely and adds a cache-miss origin-fetch charge (~$0.02/GB) on top of viewer egress.

Migration plan

Two separately reversible steps. Step one moves the zone to Cloudflare as an exact copy, apex still resolving to today’s CloudFront distribution — users see nothing, and anything that breaks is a mis-copied record. Step two, later, repoints the apex and www at the new edge — flipped and rolled back by one proxy toggle per record.

The zone lives in the current Cloudflare account (the one that already holds the bioc-site Worker, Workers Paid and R2 Paid). Moving to a dedicated Bioconductor account is deferred; see Cloudflare account migration.

Where things stand (2026-09-28, after the switch)

Cloudflare account 55bf7202fe14474e57a300f56a652f64
Zone ID 8346d8f51aa2490ebf0124f40c2f3cd0
Zone status / plan Active since 17:29:00 UTC 2026-09-28; Universal edge certificate active / Free
Assigned nameservers brynne.ns.cloudflare.com, will.ns.cloudflare.com
Records 149, all DNS only (grey cloud), TTLs matching Route53
Diff vs Route53 empty on both Cloudflare nameservers (dns/verify-zone.sh)
Bot Preference Sync off (it would rewrite robots.txt once proxied)
Registrar Route53 Domains in AWS account 555219204010; auto-renew on, transfer lock on, expires 2026-11-19; DNSSEC not configured, no DS record
Route53 hosted zone Unchanged, NS TTL 3600 (lowered 15:49 UTC 2026-09-28). Rollback target: leave untouched until 2026-10-12

Switch log (2026-09-28)

UTC
15:22 Zone created in Cloudflare; records imported, reset to DNS only, verified
15:49 Route53 NS TTL lowered 172800 → 3600 (#24)
15:59 Pre-switch check: 0 differences on both Cloudflare nameservers
~17:00–17:30 Registrar nameservers changed to brynne/will.ns.cloudflare.com
17:29 Cloudflare zone Active (activated_on 17:29:00); Universal certificate active shortly after
17:32 .org delegation shows only the Cloudflare pair; no DS. A trace from the root resolves via Cloudflare. Route53 vs Cloudflare still 0 differences. Site 200 via CloudFront (apex, www); MX/DMARC served by Cloudflare; git SSH, blog. (Pages), bioc2026. (Netlify), support. all OK. 1.1.1.1, 8.8.8.8 and 9.9.9.9 still had the AWS NS cached, as expected
18:14 8.8.8.8 on the Cloudflare nameservers
18:44 9.9.9.9 on the Cloudflare nameservers: all three public resolvers moved. Both diffs still 0, services unchanged. Watch ended
~20:09 Step 3: apex and www switched to Proxied. First Worker access records: apex 20:08:57, www 20:10:18
22:34 Firewall rule blocking a crawler loop on /talks/ from two networks (bioc-edge#32)
22:35 Browser Cache TTL 4 h → “Respect existing headers” (bioc-edge#38)

Still to confirm by hand: a real mail round trip (forwardemail in/out, one Brevo send). The 28-day pending deadline no longer applies; the zone is Active.

How the copy was made, so it can be redone:

  • dns/route53-index.txt — every record’s name, type and TTL, read from the Route53 console (152 records; Route53 allows no zone transfer and the available AWS role has no CloudShell).
  • dns/export-zone.sh — asks Route53’s own nameserver for every value in the index and writes dns/bioconductor.org.zone. dns/bioconductor.org.cloudflare-import.zone is the same minus three records (corrected 2026-09-30): the apex CNAME, which was added by hand, and the two TXT records on the literal @ label, which Cloudflare rejects (below).
  • Imported through the dashboard’s zone-file upload. That upload marks every A and CNAME record Proxied with TTL Auto — all 110 were reset to DNS-only with their Route53 TTLs through the API. Any re-import must do the same.
  • dns/verify-zone.sh — compares every record between two nameservers; exit status is the number of differences.

Deliberate differences from Route53:

Record Route53 Cloudflare Why
apex bioconductor.org Alias A → d3hzwifbu1gvt4.cloudfront.net CNAME (flattened) → same, DNS only, TTL 300 Aliases are Route53-only
www Alias A → apex CNAME → bioconductor.org same
testweb Alias → d3h1507zzd6849.cloudfront.net not copied That distribution no longer exists; Route53 already answers nothing
bbr, *.bbr weighted: 200 → 149.165.153.78, 0 → 104.45.191.146 (AKS fallback) with health checks single A → 149.165.153.78 Failover needs Cloudflare Load Balancing; both are delete candidates
TXT on a literal @.bioconductor.org label present not copied Cloudflare rejects the name; it’s a data-entry error, the real SPF is at the apex
NS, SOA AWS Cloudflare’s own expected

2. Change the nameservers

2a. Lower the Route53 NS TTL — at least 2 days before 2b

After a nameserver change, a resolver keeps using the old nameservers until its cached NS record expires. There are two copies of that record: the .org registry’s (3600 s, not ours to change) and the one the old provider serves itself, which some resolvers prefer. So each direction’s tail is set by the provider being left:

Direction TTLs that matter Worst-case tail
Switch to Cloudflare (2b) .org 1 h; Route53 NS — 172800 s today, 3600 s after this step 2 days → 1 hour
Roll back to Route53 .org 1 h; Cloudflare NS, 86400 s 1 day, whatever we do here

This step shortens the switch, not a rollback. Cloudflare’s NS TTL is adjustable only as part of Foundation DNS (Enterprise), so on this zone it is fixed at a day. The step is still worth doing for two reasons:

  • It shrinks the window in which Route53 and Cloudflare must both be kept correct.
  • It makes a second attempt after a rollback clean. Resolvers that re-fetch Route53’s NS during a rollback cache it for the full TTL, so without this step the retry starts a fresh 2-day tail.

A TTL is a ceiling, not a wait. Each resolver’s clock started at its last fetch, many follow the parent’s 1 hour, and some cap long TTLs. So most traffic moves within about an hour either way, and the worst-case figures describe the last stragglers.

This changes no answers, only how long they are cached. It is safe to do any time.

In the AWS console (account 555219204010, the NIH DNS role):

  1. Open Route 53 → Hosted zones (https://us-east-1.console.aws.amazon.com/route53/v2/hostedzones).

  2. Click bioconductor.org (hosted zone ID Z2LMJH3A2CQNZZ).

  3. On the Records tab, tick the checkbox of the row with Record name bioconductor.org and Type NS. It is the third row. Tick only that one row.

  4. Click Edit record in the details panel on the right.

  5. Leave Record name empty and Record type NS. Do not touch the Value box. It must still list exactly these four lines:

    ns-1784.awsdns-31.co.uk.
ns-1459.awsdns-54.org.
ns-876.awsdns-45.net.
ns-91.awsdns-11.com.

  6. In TTL (seconds), replace 172800 with 3600.

  7. Click Save. The banner reads that the record was updated; the change status goes from PENDING to INSYNC within about a minute.

  8. Check from a terminal — the second column must read 3600:

    dig +norec +noall +answer @ns-1784.awsdns-31.co.uk bioconductor.org NS

  9. Note the time. Step 2b should start 48 hours later, when the last 172800-second cache entries have expired. If it slips, nothing breaks: the switch just has a longer tail, and it doesn’t change how fast a rollback is.

Equivalent with the AWS CLI, for anyone with a profile in that account:

aws route53 change-resource-record-sets --hosted-zone-id Z2LMJH3A2CQNZZ \
  --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"bioconductor.org.","Type":"NS","TTL":3600,"ResourceRecords":[
      {"Value":"ns-1784.awsdns-31.co.uk."},{"Value":"ns-1459.awsdns-54.org."},
      {"Value":"ns-876.awsdns-45.net."},{"Value":"ns-91.awsdns-11.com."}]}}]}'

Undo: the same edit with 172800. Nothing else in the zone needs a TTL change: apex and www are already 300 s in the Cloudflare copy.

From here until two weeks after 2b: record freeze. Any change to the zone is made in both Route53 and Cloudflare, or not at all — the rollback depends on Route53 being right.

2b. Switch

  1. Re-verify on the day. The zone must not have drifted since the copy:

    ./dns/verify-zone.sh | tail -1        # must print "== 0 differing record(s)"
B=will.ns.cloudflare.com ./dns/verify-zone.sh | tail -1

    Also confirm the Route53 console still says Records (152). The script only checks names in the index, so a record added in Route53 since 2026-09-28 shows up as a count mismatch, not a diff — add it to Cloudflare and the index first.

  2. Copy the two nameservers from the Cloudflare dashboard (bioconductor.org → Overview). Copy them; do not type them.

  3. AWS console → Route 53 → Registered domains → bioconductor.org → Actions → Edit name servers. Replace the four awsdns entries with brynne.ns.cloudflare.com and will.ns.cloudflare.com (only those two). Save. Do not transfer the registration, and do not turn on DNSSEC.

  4. Watch the parent:

    dig +short NS bioconductor.org @$(dig +short NS org. | head -1)

    It shows the Cloudflare pair within minutes. Then click Check nameservers now on the Cloudflare Overview page. The zone turns Active, and Cloudflare sends an email, within minutes to a few hours.

  5. Post-checks once Active:

    • A=1.1.1.1 ./dns/verify-zone.sh and A=8.8.8.8 ./dns/verify-zone.sh — the public view against Cloudflare, expect 0.
    • curl -sI https://bioconductor.org/ | grep -i via still shows CloudFront.
    • Send a message to and from a @bioconductor.org address (forwardemail), and check a Brevo send.
    • ssh -T git@git.bioconductor.org still reaches gitolite.
    • Spot-check a GitHub Pages site (blog.) and a Netlify one (bioc2026.).

Rollback: Registered domains → bioconductor.org → Actions → Edit name servers → put back exactly:

ns-1784.awsdns-31.co.uk
ns-1459.awsdns-54.org
ns-876.awsdns-45.net
ns-91.awsdns-11.com

Most resolvers move back within the parent’s 1 hour. Cloudflare’s own NS records carry 86400 s (not adjustable on this plan), so a few resolvers keep asking Cloudflare for up to a day. That is harmless only if the Cloudflare zone keeps serving the same data. On rollback, leave the Cloudflare zone in place and unchanged for at least two days before deleting or editing it.

Only roll back the nameservers when Cloudflare’s DNS service is the problem. A wrong or missing record is faster to fix in Cloudflare itself (records carry 300 s TTLs), and every resolver sees the fix, including the ones a rollback would leave behind.

Afterwards: leave the Route53 hosted zone untouched for at least two weeks (it’s the rollback target), then lift the freeze. Enable DNSSEC in Cloudflare only after that, as its own change.

3. Flip the site (M1 proper)

Mechanism: a Workers route plus the proxy toggle, not a Workers Custom Domain.

  • A route (bioconductor.org/* → bioc-site) only intercepts traffic on proxied records. It can be deployed days ahead and sits inert while apex and www are DNS only.
  • The flip is switching those two records to Proxied. The rollback is switching them back to DNS only. At that point traffic goes straight to CloudFront again, because the CNAME to the CloudFront distribution never changed. That’s two clicks, with no deploy and no record deletion.
  • A Custom Domain needs the existing record deleted, then recreates and owns it itself. The rollback target would be gone and would have to be retyped under pressure.
  • The routes go in worker/wrangler.jsonc in bioc-edge (then bioc-cloudflare), not the dashboard. wrangler deploy replaces a Worker’s routes with the config’s, so a dashboard-only route disappears on the next deploy.

Before the flip:

  1. Edge certificate. After the zone goes Active: SSL/TLS → Edge Certificates must show the Universal certificate (bioconductor.org, *.bioconductor.org) as Active. Proxying before it is Active serves TLS errors. Set SSL/TLS mode to Full (strict); CloudFront holds a valid certificate for the names, so any request the Worker passes to origin still verifies.

  2. Logging (ADR 0003): the Worker’s Logpush job is delivering, and a record-count alert exists. Once traffic moves, CloudFront logs stop accruing.

  3. Plain HTTP. Decide whether to turn Always Use HTTPS on (it matches production’s 301). It only affects proxied names.

  4. Rehearse on a spare name. Add next.bioconductor.org CNAME → bioconductor.org, Proxied, plus a route next.bioconductor.org/*. Run cutover-diff.sh (bioc-edge; then bioc-cloudflare) against it. This catches any place the Worker assumes the dev hostname.

  5. Deploy the routes (inert until proxied). In worker/wrangler.jsonc:

    "routes": [
  { "pattern": "bioc-dev.cancerdatasci.org", "custom_domain": true },
  { "pattern": "bioconductor.org/*",     "zone_name": "bioconductor.org" },
  { "pattern": "www.bioconductor.org/*", "zone_name": "bioconductor.org" }
]

    Confirm under Workers Routes in the zone that both appear.

Flip: DNS → Records. On the bioconductor.org CNAME, click Edit, switch Proxy status on, and Save. Repeat for www.

Verify: - curl -sI https://bioconductor.org/ and https://www.bioconductor.org/ show server: cloudflare and no via: … cloudfront. - Run cutover-diff.sh against production. - Watch Workers → bioc-site → Metrics for errors, and the Logpush destination for records.

Rollback: the same two records, Proxy status off, then Save. Resolvers holding Cloudflare’s addresses expire within 300 s. Leave the routes deployed; they are inert again. Keep CloudFront and master running until M2 retires them.

Found along the way — fix separately, not during the move

  • The spreadsheet lists a TXT record on a literal @.bioconductor.org label carrying v=spf1 include:spf.forwardemail.net -all. It is a data-entry mistake for the apex. Route53 serves it at that literal name, and Cloudflare refuses the name. The apex has no SPF record at all (checked 2026-09-28). Its TXT records are only acevhogcbpv6dssaq15fbe1ek8, a Brevo code and a forwardemail verification, and the include:_spf.mlsend.com SPF seen in the 2026-09 review is gone. With _dmarc at p=reject, mail from the domain now depends on DKIM alignment alone. Add a real apex SPF (forwardemail + Brevo + SES) as its own change, in both zones during the freeze.
  • The apex TXT value acevhogcbpv6dssaq15fbe1ek8 has no recorded owner.
  • testweb is an Alias to a CloudFront distribution that no longer exists — delete it from Route53.
  • bbr/*.bbr still carry a Route53 health-checked failover to an AKS address. Delete them, along with the health checks (which bill monthly).
  • Since the 2026-09 review, several delete candidates are already gone (tokay*, merida*, malbec*, machv2, celaya2, monitor, docbuilder, kjohnson1, meet). New since then: autoconfig/autodiscover (forwardemail), status, testgalaxy, eurobioc2027, the Brevo DKIM selectors. Many A-record targets also moved (e.g. workshop is now 149.165.152.155). The per-host detail below predates this and is not re-probed.

Core infrastructure, staying put (27)

Marked “keep” in the source review, not touched by the M1 apex/www flip. Visited each directly (curl -sI https://<host>/) rather than assuming from the hostname.

master.bioconductor.org

A → 52.71.54.154. Live — full production bioconductor.org mirror. This is the legacy master webserver being retired by the M1/M2 migration.

staging.bioconductor.org

A → 52.4.245.79. No public HTTPS response. Confirmed elsewhere in this repo (see the decommission plan) that no web server listens here — this is the legacy build host, not a public site.

git.bioconductor.org

A → 34.192.48.227. Confirmed live: gitolite3 v3.6.6 serving the package git repos directly (admin/…, packages/ABAData, …) — this is the canonical package source, not a redirect target.

chat.bioconductor.org

A → 34.192.48.227. Same redirect target as zulip.bioconductor.org — an alias into the same Zulip Cloud instance.

zulip.bioconductor.org

A → 34.192.48.227. Redirects to the team’s hosted Zulip Cloud instance (community-bioc.zulipchat.com) — the real chat entry point.

www.zulip.bioconductor.org

A → 34.192.48.227. No public response. Correction 2026-09-30: it answers over HTTPS with the gitolite listing that git serves, but its certificate (*.bioconductor.org) doesn’t cover a two-level name, so certificate checks fail. Shares its target IP with zulip/chat/git/packages — routing for www.-prefixed vhosts on that box looks inconsistent.

www.chat.bioconductor.org

A → 34.192.48.227. No public response, same shared-IP pattern as www.zulip. Correction 2026-09-30: same as www.zulip, it answers with the gitolite listing and fails certificate checks.

packages.bioconductor.org

A → 34.192.48.227. Redirects to the Open Storage Network archive bucket — a convenience alias so people don’t need the full OSN URL to browse package archives.

support.bioconductor.org

A → 54.164.10.157. Live — the Bioconductor Support Forum (Django app, Biostars-derived).

issues.bioconductor.org

A → 52.4.116.154. Responds but the body is literally “Nothing to see here” — currently a stub. Worth checking whether the real issue tracker moved elsewhere, or this is mid-decommission.

code.bioconductor.org

A → 194.94.45.72. No public HTTPS response — purpose unconfirmed from outside; worth a direct look. Correction 2026-09-30: it serves “Bioconductor Code”, a site to browse and search package source, but its certificate expired on 2026-08-30, so certificate checks fail.

rabbitmq.bioconductor.org

A → 52.20.79.236. No public HTTPS response — a message broker (STOMP/AMQP), expected to not answer on plain HTTPS; the SPB build-results pipeline depends on it (see the decommission plan).

pkgmaintainers.bioconductor.org

A → 44.218.162.37. Live — “API Summary,” a maintainer-facing API service.

annotationhub.bioconductor.org

A → 52.73.93.102. Live — “BiocHub Server API,” the AnnotationHub backend.

experimenthub.bioconductor.org

A → 52.73.93.102. Live — same BiocHub Server API, serving ExperimentHub instead of AnnotationHub.

nebbiolo1.bioconductor.org

A → 155.52.47.135. No public HTTPS response — a dedicated Linux package-build machine (release), not a webserver.

nebbiolo2.bioconductor.org

A → 155.52.47.146. No public HTTPS response — same role as nebbiolo1, devel branch.

kjohnson3.bioconductor.org

A → 172.24.216.75. No public HTTPS response — a macOS package-build machine.

workshop.bioconductor.org

A → 149.165.171.210. No public HTTPS response — workshop compute cluster, likely gated (auth or VPN) rather than dead.

workshopauth.bioconductor.org

A → 149.165.154.124. No public HTTPS response — the auth front-end for the workshop cluster above.

webr.bioconductor.org

A → 149.165.154.124. No public HTTPS response despite “keep” status — serves a WebR package repository; each version needs its own path (e.g. /3.23) rather than a splash page at the root, which may explain the empty response at /.

run.webr.bioconductor.org

A → 149.165.154.124. No public HTTPS response — reserved for a planned in-browser WebR demo page (fully client-side, eventually movable to GitHub Pages).

discourse.dev.bioconductor.org

A → 149.165.153.32. No public HTTPS response despite “keep” status — a dev/staging Discourse instance; may only answer on a non-standard port or be gated.

isee.bioconductor.org

A → 149.165.171.200. Live Shiny app — linked to the Bioconductor/isee.bioconductor.org GitHub repo. The wildcard *.isee.bioconductor.org is kept for the same app; check with the app’s maintainer before touching either.

hubsingest.bioconductor.org

A → 149.165.171.200. No public HTTPS response — an ingestion endpoint, not a browsable site. Kept for an active hub-ingestion workflow; confirm it’s still in use before any change.

certs.bioconductor.org

A → 149.165.171.200. Live — the BiocCertificate Shiny app for issuing training certificates.

workinggroups.bioconductor.org

CNAME → bioconductor.github.io. Live — GitHub Pages site for Bioconductor Working Groups.

training.bioconductor.org

CNAME → bioconductor.github.io. Live, but the page title is just “index” — likely a generic template; content itself may still be fine, the title tag just isn’t descriptive.

contributions.bioconductor.org

CNAME → bioconductor.github.io. Live — “Bioconductor Packages: Development, Maintenance, and Peer Review,” the package contribution/review site.

blog.bioconductor.org

CNAME → bioconductor.github.io. Live — the community blog, GitHub Pages.

Undecided — needs an owner (18 with live content or a clear guess; 24 more listed in the appendix table are wildcards or mail/cert plumbing)

testweb.bioconductor.org

A → d3h1507zzd6849.cloudfront.net.. No public HTTPS response. Points at a second, separate CloudFront distribution (d3h1507zzd6849.cloudfront.net, different from production) — worth checking what that distribution is before the main cutover, in case it needs retiring alongside it.

testinggit.bioconductor.org

A → 44.207.152.77. No public HTTPS response — looks like a test git host, name suggests safe to retire once confirmed unused.

support.test.bioconductor.org

A → 44.210.209.116. No public HTTPS response — test instance of the support forum.

slack.bioconductor.org

A → 34.192.48.227. Serves a generic “Countdown with Embedded Blog” template — not Slack-branded content. Whatever this vhost used to do, it no longer matches its hostname; worth a direct look before deciding keep/delete.

posters.bioconductor.org

CNAME → bioconductor.github.io. No public HTTPS response despite pointing at GitHub Pages — check whether the underlying Pages site still exists.

pm-bounces.bioconductor.org

CNAME → pm.mtasv.net. No public HTTPS response — mailing-list bounce handling (Postmark), not meant to be browsed.

osca.bioconductor.org

CNAME → bioconductor.github.io. Live — redirects into “the OSCA book” (Orchestrating Single-Cell Analysis), an external teaching resource.

osca-dev.bioconductor.org

CNAME → bioconductor.github.io. Same pattern as osca, development version.

new.bioconductor.org

A → 52.71.54.154. Live, and resolves to the same IP as master.bioconductor.org, serving an identical “Bioconductor - Home” page. Looks like a leftover alias rather than a distinct site — worth confirming with the team before assuming it can be dropped.

meet.bioconductor.org

A → 54.82.236.113. No public HTTPS response — purpose unconfirmed; hostname suggests a meeting/scheduling tool.

gitdevtest2.bioconductor.org

A → 149.165.171.129. No public HTTPS response — second test git host, same IP as the first.

gitdevtest.bioconductor.org

A → 149.165.171.129. No public HTTPS response — test git host.

federated-packages.bioconductor.org

A → 149.165.155.146. No public HTTPS response — purpose unconfirmed; name suggests an experimental federated package-serving effort.

courses.bioconductor.org

A → 52.54.47.64. No public HTTPS response — purpose unconfirmed.

core-sops.bioconductor.org

CNAME → victorious-wave-0b018b710.4.azurestaticapps.net. Live, redirects to a /login/ page — internal SOPs site (Azure Static Web Apps), access-gated as expected.

cfp.bioconductor.org

A → 3.139.155.94. No public HTTPS response — hostname suggests a call-for-proposals form, possibly tied to a past conference and safe to retire, but unconfirmed.

auth.bioconductor.org

A → 149.165.153.78. No public HTTPS response — likely an internal auth service (the wildcard *.auth.bioconductor.org mirrors it). Undecided status suggests this needs an owner check.

anvil.bioconductor.org

CNAME → bioconductor.github.io. Live — BiocAnVIL project pages, part of the AnVIL cloud-genomics collaboration.

Already off AWS — no action (27, one table)

Event-site CNAMEs (bioc20{18..26}, biocasia20{20..26}, eurobioc20{19..26}, gbcc2025) plus dev.status, and fe-bounces — all confirmed live, all pointing at GitHub Pages, Netlify, or forwardemail.net. None resolve through CloudFront, master, or staging — the cutover is invisible to them.

Delete candidates (25) — confirmed unreachable

Every host in this list returned no public HTTPS response in the probe, consistent with being retired already: tokay1/2, merida1/2, malbec1/2, machv2, celaya2, monitor, docbuilder, kjohnson1, k8slaunch, js2launch, bbr (×2), yescure(cluster), prodaks — plus seven tagged “delete end of 2026” (workshopk8s, workshopcluster, prodk8s, hsdsdev, cloudman.kubeinstall, ci-mirror, biocworkshop), presumably tied to a class or grant ending. The probe is supporting evidence for the delete call, not proof — “no public HTTPS” doesn’t rule out an internal-only service still in use.

Mail/cert plumbing and wildcards, undecided (24)

Not individually probed — none of these are meant to serve HTTP content. ACM certificate-validation CNAMEs (_....acm-validations.aws.) and DKIM selector CNAMEs need re-verification against whatever currently sends mail as bioconductor.org, not assumption of obsolescence. The wildcard records (*.workshop, *.auth, *.bbr, …) mirror a decision already made on their base hostname above but weren’t themselves tagged — worth confirming they’re meant to inherit it rather than being reviewed independently.

Open questions for the core team

  • Apex mechanism — settled 2026-09-17: nameserver migration to Cloudflare, see the migration plan.
  • Dedicated Bioconductor Cloudflare account: deferred until after the cutover; see Cloudflare account migration. Still needs super administrators and a billing owner named.
  • R2 object count for bioc-site and bioc-prop — sizes the account-move copy (time and write-operation cost).
  • Plain-HTTP behaviour on the new edge: redirect to HTTPS like production, or serve 200?
  • Which SPF record is intended at the apex, and who owns the unlisted apex TXT value?
  • new.bioconductor.org mirrors master.bioconductor.org exactly (same IP, same content) — leftover alias or intentional?
  • slack.bioconductor.org serves a generic template unrelated to its name — check what this vhost is actually for.
  • issues.bioconductor.org responds with a bare “Nothing to see here” — confirm whether the real tracker moved.
  • Confirm the 18 undecided hosts above, especially the stale-looking test hosts (testweb, testinggit, gitdevtest, gitdevtest2, support.test) and the second CloudFront distribution behind testweb (d3h1507zzd6849.cloudfront.net, distinct from production — does it need retiring too?).