Migrating Domains

• Setting the Scene
• The Checklist
  • Mail
  • Security Keys
• Homelab
• Website
• Services
• Conclusion

Setting the Scene

I was recently on Namecheap, my domain registrar of choice, reviewing my domain sua.sh when one called sua.dev caught my eye. This domain is particularly attractive for three reasons: 1) my nickname is sữa (milk in Vietnamese), 2) three letter domain names are aesthetically pleasing and rare, and 3) the .dev top-level domain (TLD) is perfect for tech-focused blogs.

As an aside, I learned that the .dev TLD was proposed by Google back in 2019. This wasn’t the selling point, but it’s cool to see a big company like them behind it.

It wasn’t cheap. For transparency, it is an $115 per year subscription. A domain name a little longer like jhoang.dev or justinh.dev goes for about $15 a month. Nevertheless, compared to my previous subscription for sua.sh, which was about $50 per year, I feel more in love with sua.dev, and I am happy to pay more for that premium domain. At the time, I don’t believe that the sua.dev was available, or else I would have gone with it. I figure that if I’m going to be renting a domain, it better be one that I actually like.

The Checklist

Migrating domains is no simple task. I had emails, security keys, services, documents, and more tied to my old email.

Mail

I am using Proton Mail for my developer email. Proton Mail allows you to use custom domains with their email if you have the premium subscription. This is nice because I can use and share a more personalized email that uses my own domain whilst enjoying all the features I would expect from a premium email service.

After about half a year of experimenting, I may be canceling this subscription and just using iCloud+’s custom domain service. While I understand Proton Mail’s focus on privacy and security, but I don’t think it it’s worth the $5 a month that I’m paying. I don’t particularly use my personal or developer email that often anyway. Moreover, I am already paying for iCloud+ for $2.99 a month, so I should take advantage of this benefit!

Anyway, adding an updated email was pretty simple. Here are the steps:

In Proton Mail,

1. Navigate to Settings > Domain names
2. Delete the old domain (if applicable)
3. Click ‘Add a Domain’ and follow the instructions
4. Wait 30-60 minutes for DNS propagation
5. Navigate to Settings > Identity and addresses
6. Add the new address
7. Your new email (with your new domain) should be ready to use!

In your domain registrar console, fill out all the records that Proton asks for. This allows for Proton to verify that you do, in fact, own the domain.

You will be asked to create several CNAME, TXT, and MX records. All you have to do is copy and paste the values that Proton Mail tells you to.

Security Keys

I am using GPG to sign my git commits. This lets me get nice verified commits which is 1) aesthetically pleasing and 2) gives myself and others a better sense of peace that these code changes came from the correct person.

Updating the email for these GPG keys requires you some command line wrangling. These are all of the commands necessary. The steps go something like this:

1. Find the GPG key that you want to change
2. Add a new UID with your new email
3. Optionally delete or invalidate your old UIDs
4. Set the new UID as primary
5. Save the changes

Here are the corresponding commands.

# list the keys
$ gpg -k

# edit the key
# you'll be dropped into a REPL. use the help command for more information
$ gpg --edit-key <THE_KEY_UNDER_QUESTION>

# list the existing uids on the key
$ list

# add a new uid on the key (follow the prompts)
$ adduid

# select the active uid
$ uid

# set the active uid to be the primary uid
$ primary

# delete the uid (optional)
$ deluid

# revoke the uid (but keep it) (optional)
$ revuid

# save the public key data into the clipboard
$ gpg --armor --export <YOUR_EMAIL> | wl-copy

Finally, we can copy the public key data and save it to GitHub.

Homelab

Most services running on my homelab are accessible through web interfaces. I generally use this format: service_name.sua.sh so that it’s easy to remember. For example, my recipe manager Mealie is reached through mealie.sua.sh, but now I want to reach Mealie through mealie.sua.dev.

Running NixOS on my servers means that updating the domain was a one step process. In fact, this is the single change that updated all my servers and laptops. Generating the SSL certificates is done automatically as well using the ACME module, so all of these services are reachable through https:// prefixes. No scary warnings from the browser at all!

As an aside, SSL is enforced with no exceptions for .dev domains because it is included on the HSTS preload list.

All it takes is a simple nixos-rebuild switch and everything is back up and running within the hour.

Website

Setting up my website to use the sua.sh domain was as simple as changing the CNAME file and updating a few DNS records that GitHub requires. Refer to the table for the values you need to add. The hardest part is waiting for the DNS system to propagate your changes and SSL certificates to be generated.

Make sure you add CNAME records for the @ (root) and www subdomain so that you can access your website in two ways: sua.dev and www.sua.dev. Both URLs will be redirected one another.

Services

The final thing to do is to update my old justinhoang@sua.sh emails to justinhoang@sua.dev. There was probably a smarter way for me to do this before completely switching, but meh it’s okay. It’s a bit difficult to remember which ones are actually important, but meh. I think if it’s important enough, then I’ll remember.

Conclusion

All in all, I am happy with this new purchase, even though it’s on the expensive side. I promised myself that I was going to start migrating emails from my Gmail account, but I never got to it. I think this time, with my new domain, I’ll get around to it.