DNS 301 update for boston.pm.org

[n1vux]

Can we please redirect boston.pm.org to https://boston-pm.github.io/ ?

Backstory: Alas our second free wiki provider was also worth every penny; they left the server up after folding the business as a courtesy, but didn't renew the primary domain, so now all traffic goes to a domain squatter. Longer-term plan is to have boston.pm.org actually address a cloud server, probably under The Perl Shop's umbrella, at which point the github.io Pages would become the staging view. But today, using it as the main site is better than nothing. And with a git-centric workflow, loss of a server won't threaten a loss of history.

// Bill Ricker, facilitator, Boston.pm

[jhannah]

DNS request 135348 submitted, should take in a business day or so.

[n1vux]

Thanks Jay!

[n1vux]

Hmm, that gave us a CNAME record, not a 301/302 redirect like we had before (to the wiki).

GitHub.io has HSTS and provides generic HTTPS certificate for *`.github.io** but not for the boston.pm.org CNAME, they don't know about it. So this givesSSL_ERROR_BAD_CERT_DOMAIN` if the browser uses the alias instead of the real name to validate the certificate (I could argue this is a browser bug, but FF and Chromium agree it's a security issue - defending against DNS poisoning, i think?)

Until we can put up our own server capable of asserting boston.pm.org and hosting a Let's Encrypt cert with that name, i think we need the prior boston.redirects.pm.org (a CNAME for kube.pm.org=ewrlb.develooper.com)'s 302 Location: redirect service that we previously had to qualitybox.us to now point to URL https://boston-pm.github.io/

(If you worked off the email notification of the original request, in which i hadn't specified https:// until i edited this issue after reading the FAQ on (re)starting a new (dormant) PM (which we aren't, but it told me how to reset the lat-lon away from our lost meatspace building), this confusion would be my fault.)

as-was

;; ANSWER SECTION:
boston.pm.org.      7119    IN  CNAME   boston.redirects.pm.org.
boston.redirects.pm.org. 7119   IN  CNAME   kube.pm.org.
kube.pm.org.        219 IN  CNAME   ewrlb.develooper.com.
ewrlb.develooper.com.   1119    IN  A   139.178.67.96

as-is

;; ANSWER SECTION:
boston.pm.org.      7163    IN  CNAME   boston-pm.github.io.
boston-pm.github.io.    3563    IN  A   185.199.111.153
boston-pm.github.io.    3563    IN  A   185.199.110.153
boston-pm.github.io.    3563    IN  A   185.199.109.153
boston-pm.github.io.    3563    IN  A   185.199.108.153

[n1vux]

(OTOH, this is still an improvement over the prior condition of redirecting to a domain-squatted site that has at best vicious tracking ads and possibly truly malicious warez; it's safe and over-warned, rather than more or less unsafe and possibly under-warned.)

[jhannah]

hmm... well, years ago, in our WebDAV era, I used to have access to an Apache configuration file of sorts so I could submit a DNS request to point your DNS to our Apache server and then redirect groups to any arbitrary URL... @rspier does that system still exist in our current "Jay only modifies github" universe?

[n1vux]

(division of roles is good for security !)

(provided of course it doesn't become a pipeline of Bus Factor = 1 nodes )

[rspier]

Sorry for the delay, I didn't realize more action was required from me in a time-sensitive fashion.

@n1vux Have you configured the custom domain? https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages#https-errors

@jhannah I thought it still existed, but I couldn't find it last week. I found it tonight, and you do have access, but you've never used it. It hasn't been updated since 2019, and there was only one that entire year. Based on that usage, I suspect it's another feature we can consider moving into read only mode. (Because it effectively is.) Almost everyone is moving to GitHub pages which doesn't need it. This also means there may be 108 group websites we're still hosting in read-only mode that haven't been updated since 2017. I'll add those to the spring cleaning list.

[n1vux]

Robert @rspier - OHHH. i hadn't seen the referenced page. I had searched for such but didn't find. And rather (naively? pessimistically?) presumed that if there was support for custom-domains (beyond ${name}.github.io subdomains, pretty decent as it was), they'd have reserved if for paid accounts. I will take a look and see if ican be a ^self-rescuing princess^ !

[n1vux]

Aha. In order to verify that i am authorized to assert boston.pm.org from github, since it already exists in DNS, they need me (us, @rspier ) to create a TXT record demonstrating authorization -

1. Create a TXT record in your DNS configuration for the following hostname: _github-pages-challenge-n1vux.boston.pm.org
2. Use this code for the value of the TXT record: 617741bc1bd26ecdd864538b3d22dd

3. Wait until your DNS configuration changes. This could take up to 24 hours to propagate.

   (The page with those directions)

[rspier]

Done!

Maybe I chose poorly, this is exactly the kind of custom DNS stuff I want to avoid :). I should clearly figure out how to bring back the redirects configuraiton file.

[rspier]

$ dig +short txt _github-pages-challenge-n1vux.boston.pm.org
"617741bc1bd26ecdd864538b3d22dd"

[n1vux]

Ugh, that verified it for me but not for Your Organizations. I didn't scroll down far enough

[n1vux]

Sorry Robert @rspier , can we please ~change~ replace that undesired TXT as follows so i can switch ownership from me n1vux to boston-pm ?

1. Create a TXT record in your DNS configuration for the following hostname: _github-pages-challenge-boston-pm.boston.pm.org
2. Use this code for the value of the TXT record: 5180a68883dc45f788f36788ee3b52
3. Wait until your DNS configuration changes. This could take up to 24 hours to propagate.

sigh

[rspier]

Done. Sorry for the delay.

[n1vux]

Thanks. Hopefully it will percolate through DNS to me and them soonish.

[n1vux]

This is getting weirder. (1) i got it verified, and dropped it from my personal list, but GH-io still errors

 The custom domain `boston.pm.org` is already taken. If you are the owner of this domain, check out https://docs.github.com/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages for information about how to verify and release this domain. 

(2) dig shows CNAME and github.io addresses as expected, but if i aim Firefox or Chrome to boston.pm.org, i now get an Arabic page, not the bad-certificate message I had been getting. Now i'm thoroughly confused. The site has a LetsEncrypt cert dated 9/15 for boston.pm.org . Does some root have stale copy of the old redirect ? (How are my browsers and commandline dig using different DNS caches or providers?) 8.8.8.8, 1.1.1.1, and router connected to VZ FioS agree on what i expect to see, not explaining weird result.

[rspier]

This appears to be a GitHub side problem.

Someone else (somehow) has verified this domain.

I'd suggest going through the verification process again.

I'll also try and find time this weekend to figure out how best to modify the redirect configuration that hasn't been touched in years.

[rspier]

I went back to the "redirect" mechanism, and it's good to go.

[rspier]

$ curl https://boston.pm.org/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://boston-pm.github.io/">here</a>.</p>
</body></html>