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.

[japaric]

My DNS-foo is weak and I just heard about terraform recently but this looks reasonable to me.

@ryankurte and @jamesmunns could you also take a look?

[ryankurte]

The terraform looks good to me! Haven't tried executing it, but given the records seem right I'd be happy with a swap over.

The only questions I still have are around AWS billing / pricing / management. Particularly who owns the management account (maybe we could use a rust-embedded-ops@rust-lang.org address or something to pin everything on @japaric?, it just has to not be on one of the domains we're managing with it).

[jamesmunns]

I also don't know terraform, but a quick skim over the linked repo makes sense to me.

Do we want to go ahead and add a blog.rust-embedded.* alias now? We can always land it as a PR after the initial support is accepted.

[japaric]

Particularly who owns the management account

Right now that'd be @nastevens.

maybe we could use a rust-embedded-ops@rust-lang.org

We can ask the Rust team to create e-mail aliases for us but does it have to be @rust-lang.org account? If this is for management I don't think it has to be an official looking account as it won't necessarily be a "user facing" e-mail.

Would it make sense to instead turn the e-mail of each member of the future ops team into a manager of the AWS account? (If that's possible; I don't exactly recall how AWS management works)

---

@nastevens I think this is ready to go.

We should create a formal ops team that manages the new repo shortly after the new infra is in place. Any volunteers? We can make you a collaborator of the repo before the ops team is formed.

[ryankurte]

I'm happy to be on the ops team too ^_^

[nastevens]

All sounds good.

@japaric I won't be able to join the meeting today, but I will plan to cut everything over this afternoon. If I did it right, we shouldn't even notice 😄

[nastevens]

DNS records are propagating and so far everything looks good. Might take up to 48 hours before all the caches are cleared, so we'll want to keep an eye on things.

http://embedonomicon.rust-embedded.org is a new DNS entry so it should work right out of the gate and looks good from my end.

One issue I've noticed so far is that http://embedonomicon.rust-embedded.com doesn't get picked up by GitHub pages, which only allows a single custom domain. We can get around this by setting up an HTTP redirect for that domain - I'll get that taken care of.

Please let me know if anyone notices any other issues.

[nastevens]

I pushed the redirect changes, now everything looks to be in good shape. Here's the full list of domains to check:

• http://rust-embedded.org
• http://book.rust-embedded.org
• http://embedonomicon.rust-embedded.org
• http://rust-embedded.com
• http://book.rust-embedded.com
• http://embedonomicon.rust-embedded.com
• http://areweembeddedyet.com
• http://www.areweembeddedyet.com

[caemor]

The http-versions look good to me, but there is a problem with invalid ssl/tls certificates for a few of them. But as this is not a dns-issue it might be better handled in a new issue.

[japaric]

@nastevens awesome, thanks!

I'm going to close this as done. https and other issues should be reported to https://github.com/nastevens/rust-embedded-provisioning