Website: update DNS infrastructure

[nastevens]

Currently rust-embedded.org (and redirect sites rust-embedded.com and areweembeddedyet.com) have DNS managed directly by 1and1.com's DNS tools. Those tools are frankly garbage, and don't allow even basic things like multiple IP addresses on an A record.

I am planning to move DNS management to AWS Route 53 and implement the following proposed layout for rust-embedded.org:
@ -> A record pointed to Github apex IP addresses (https://help.github.com/articles/setting-up-an-apex-domain/)
www -> CNAME pointed to rust-embedded.org, which will automatically redirect to https://github.com/rust-embedded/rust-embedded-www
embedonomicon -> CNAME pointed to rust-embedded.org, which will automatically redirect to https://github.com/rust-embedded/embedonomicon
book -> A/AAAA records pointed at @jamesmunns's server at 46.101.143.249/2a03:b0c0:3:d0:0:0:cb7:5001

rust-embedded.com will redirect all subdomains to their equivalent at rust-embedded.org. areweembeddedyet.com redirects to the main page for the apex domain and www, but doesn't redirect any of the subdomains (book, embedonomicon).

Comments welcome - I will set up the AWS records first so we can try them out before cutting over the registrar to use those addresses.

CC @jamesmunns @ryankurte
Refer to rust-embedded/embedonomicon#12

[ryankurte]

I don't know what the route53 tools are like for sharing, but cloudflare supports organisational accounts (and does everything we would need + some extra goodies) for free, which our one day ops team might find useful. I'm sure the same can be achieved with route53, but I'm not sure how difficult it might be?

[jamesmunns]

Sounds good to me @nastevens, thanks for opening up this issue. I agree with @ryankurte, it would be nice not to have a single point of failure/put all the burden on you whenever we need to make changes.

[jamesmunns]

Another option would be to transfer ownership of the domain to the Rust organization itself, and manage our DNS through whatever process rust-lang.org uses. I'm not too familiar with this, or if this is a good or bad idea. @japaric might know though.

[nastevens]

Sounds like we're on a similar page - I had been thinking AWS only because that's what I'm familiar with and knew how to set up an organizational account. I didn't know that Cloudflare had an offering that would fit the bill - I'll definitely take a look at what that offers before starting the AWS stuff.

And yeah, I'd like to have other people able to make changes without having to get involved. Best case scenario I'd like to get to a point where at least one other person would have complete-enough control that the only thing they'd have to do is start paying the bills to keep the sites up. There again I'll take a look at how Cloudflare would handle that - I already know that AWS is able to give permissions to organizational accounts that would allow an admin in that account to basically "break free" of the parent, at which point it can be billed separately.

[japaric]

@japaric might know though.

Sorry, I don't know how they manage rust-lang.org DNS; you would have to ask the infra team.

[ryankurte]

The other consideration for later on is that we could automate/terraform our records to have a gh repo as the authoritative source for config and support PR changes, but, it's probably too much work for right now and we can do that with basically any provider. Maybe a job for the ops team further down the line.

[japaric]

@nastevens any news on this?

[nastevens]

@japaric Sorry, I had a family emergency last week and wasn't able to get to this. Hopefully I can get to it this week.

[japaric]

@nastevens Totally understandable. Thanks for taking the time to work on this. ❤️

[nastevens]

Sorry again for the huge delays.

I have created the AWS infrastructure listed above in a new AWS account and have it managed with the Terraform here: https://github.com/nastevens/rust-embedded-provisioning. Once we're happy with the layout, I can move the repo into the rust-embedded organization. The idea here is that we can then accept PRs into that repo and streamline any future changes, including adding accounts that can also apply changes and reduce my bus-factor.

You can test out the existing domains with dig by pointing at the specific AWS nameservers:

• dig @ns-298.awsdns-37.com. rust-embedded.org www.rust-embedded.org book.rust-embedded.org embedonomicon.rust-embedded.org
• dig @ns-218.awsdns-27.com. rust-embedded.com www.rust-embedded.com book.rust-embedded.com embedonomicon.rust-embedded.com
• dig @ns-393.awsdns-49.com. areweembeddedyet.com www.areweembeddedyet.com

Note that the nameservers are different per TLD due to the way that AWS balances DNS requests - the specific nameserver for a domain is automatically assigned when you create the zone.

Note that there is a little bit of magic going on the for the rust-embedded.com and areweembeddedyet.com TLD redirects. Because you can't create a CNAME for a TLD, those domains are performing an HTTP 301 redirect instead. The most expedient way to do that was to configure S3 to do the redirect, but that means that TLS connects are probably not going to work correctly. But they don't currently work either, so that is a problem we can tackle another time.

Once someone has had a chance to double-check my work, I will flip the switch to use the new infrastructure.