Adrian Hall

Product Architect by day; Open-source developer by night

4 minute read

Today, I’m continuing on the job of setting up a new blog. I’ve now got three blog posts, so that’s enough for me to consider what I need to do for production. I don’t have a domain yet, so this post is all about setting up the domain.

This post is part of a sequence showing how to deploy a blog on Azure Static Web Apps:

  1. Deploying Azure Static Web Apps
  2. Configuring Azure DNS
  3. Configuring Static Web Apps Custom Domains
  4. Taking Static Web Apps to Production

Step 1: Pick a name

While this seems simple enough, your domain name is likely to become your brand, so it needs some thought. All the best names are likely taken, so it will also take some research. I use whois.domaintools.com to check registrations, since most of the registrars will block someone else from finding the domain if the domain is in the shopping cart - even if that shopping cart has been abandoned.

Step 2: Pick a domain registrar

You may already have a domain registrar if you’ve registered a domain in the past. You can use the same registrar if you already have one. I use Dreamhost as my registrar. You can also use any of the ICANN Accredited Registrars. Forbes did some research and came up with a list for small businesses to use. For this task, all the registrars will offer the basic facilities we need - register a domain and allow us to set the name servers. You don’t need any of the other “value-add” services a registrar offers.

I’m definitely not recommending one registrar over the others here. It’s your money. Do your research.

Step 3: Register your domain

You’ll need to register an account with the domain registrar, select your domain, and then pay some money. You can generally decide on one to three year terms, and every domain registrar will try and up-sell you to additional services like hosting and email. I’m going to be running Azure DNS and hosting my site on Azure as well, so I don’t need any of the upsell stuff.

Step 4: Create the DNS zone in Azure DNS

Now that you have your domain, it’s time to create the domain in Azure DNS. I can do this with the Azure CLI and that is the preferred tool given that this is a one-off task. Make sure you have logged in and selected a subscription before you begin.

As with all resources, the Azure DNS Zone resource needs to be placed in a resource group. I’m going to use the same resource group as my static web app.

export DNSNAME="my-blog-domain.com"
az network dns zone create -g $RG -n $DNSNAME

Once you’ve created the domain, get a list of the DNS servers that it uses:

az network dns record-set ns list -g $RG -z $DNSNAME --query "[].NSRecords[].nsdname" --output tsv

There are many name servers for Azure DNS and your domain will be assigned to four of them that are geographically distributed.

I don’t recommend adding the DNS zone resource itself to your bicep files. There is a lot happening between creating your DNS zone resource and the DNS being correctly updated everywhere. That process (including DNS propagation) can take days. You can still use it in your bicep file (using an “existing resource” syntax).

You can create the zone using bicep. The appropriate snippet of bicep is:

1
2
3
4
5
6
7
8
9
10

> module dnszone 'br/public:avm/res/network/dns-zone:0.3.0' = {
>   name: 'dnszone-${resourceToken}'
>   scope: rg
>   params: {
>     name: zoneName
>     location: 'global'
>     tags: tags
>   }
> }
>

You have to specify the zone name (generally as a parameter) and the resource token (as a variable). I also recommend using resource locks on your domains (so you don’t accidentally delete them).

Step 5: Update the name servers in your zone

Go back to your domain registrar and edit your DNS zone. Update the name servers so that they match the list you obtained after creating the DNS zone. This is (again) a one time activity.

Warning: If you happen to accidentally destroy your infrastructure and have to re-build it from scratch, make sure you go back and update the name servers in your domain registrar. They may be different.

Step 6: Wait

It’s hard, I know. But now you have to wait for your domain to propagate everywhere. This can take as little as 24 hours, or as much as a week. Leave a long lead time for this bit.

A good check is to use nslookup.io to check your domain from your home machine (something that isn’t using Azure DNS as a resolver). Once the domain is available and the name servers listed match the Azure DNS name servers, you are ready to progress.

Step 7: Register your site with Azure DNS

Your domain is now ready but nothing is using it. It’s up to you to put the right DNS records into your zone to make it work.

My site is hosted on Azure Static Web Apps. I can set up both the domain (also known as a root domain or apex domain) and a subdomain (like www.my-blog-domain.com) as custom domains. Since I’m going to be doing this in my Azure Developer CLI infrastructure deployment, you can follow along during the next article.

Final thoughts

Azure DNS is not free - it will cost you about $0.90 per month (US) (considering both the zone charge and the query charge) unless you are running a really big domain. You can, of course, use an alternate DNS provider, but the integration between Azure DNS and the other resources, plus being able to store your DNS records alongside your other infrastructure as bicep files is a win for me.

More reading

Leave a comment

You may also enjoy

Customizing Keycloak with Aspire - Part 3

October 04, 2024  7 minute read  

This is the last article in a trio of articles about incorporating Keycloak into .NET Aspire applications. Thus far, I’ve covered the basics and some common customizations. This part covers what you need to do if you want to store the identity information within a PostgreSQL database. I’ve chosen PostgreSQL for this because it seems to be the database of choice for Aspire when you want to run things locally and in the cloud and also because the PostgreSQL database driver is included by def...

Customizing Keycloak with Aspire - Part 2

September 30, 2024  5 minute read  

In my last article, I introduced the Keycloak identity service and showed how the development version can be easily integrated into a project. Development services get you started quickly and allow you to defer the details until later on. At some point, however, you need to take control of your service and start working towards production. There are a number of things that the development version of the Keycloak identity service doesn’t do that you need in production. These include SSL/TL...

Integrating Keycloak with Aspire - Part 1

September 26, 2024  9 minute read  

In my series on ASP.NET Identity, I mentioned (several times) that you should be using Keycloak, Auth0, Corbado, or another identity service instead of rolling your own. That’s all good, but I left it up to you to figure out exactly how to do that. I thought it would be a good idea to configure an Aspire project from the beginning and show how authentication and authorization with a service works. This article will be more of a “make the code work” type of article, with follow-on articles ...

ASP.NET Identity deep dive - Part 6 (Social logins)

September 20, 2024  12 minute read  

This article is one of a number of articles I will write over the coming month and will go into depth about the ASP.NET Identity system. My outline thus far: Project setup Account registration Signing in and out with a username and password Password reset Email confirmations Social logins Now that I have the basic flows sorted out (which includes username/password with registration, self-service password reset, and account lockout support), it’s time to turn my attention to o...