5 minute read

Today, I’m continuing on the job of setting up this blog. I’ve now got three blog posts, so that’s enough for me to consider what I need to do for production. Probably the most major thing I need to do in the near future is set my blog up on a domain. 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.

After research, I settled on apps-on-azure.net as my central domain name. The sneaky folks at Amazon had already registered appsonazure.com, but there were several alternatives that I could pick. If I were a corporate entity then I would spend the money to buy the alternative domains. For mine, this would be a list like this:

  • apps-on-azure.net
  • apps-on-azure.com
  • apps-on-azure.io
  • apps-on-azure.dev
  • apps-on-azure.xyz
  • apps-on-azure.info
  • apps-on-azure.biz

… and probably the non-hyphenated versions as well. On an annual basis, this can get expensive, so I am sticking with just the one domain.

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 happen to use Dreamhost as my registrar. You can also use any of the ICANN Accredited Registrars, and Forbes did some research and came up with a list for small businesses to use. For our purposes, they are all the same - register a domain and let us specify name servers.

I’m definitely not recommending one 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 easily enough. 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.

az network dns zone create -g rg-apps-on-azure -n apps-on-azure.net

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-apps-on-azure -z apps-on-azure.net --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. Bring it in with an “existing” resource definition. This is because 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. It’s better to assume you have the DNS zone available and to bring it in for use.

Even though I do not recommend including it in your main.bicep file for the blog, you can also create this zone using bicep. The appropriate snippet of bicep is:

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). I’ll cover resource locks in a later post.

Step 5: Update the name servers in your zone

Go back to your domain registrar and edit your DNS zone. Update the name servers to be identical to the list you obtained after creating the DNS zone. This is 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. 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.apps-on-azure.net) as custom domains. Since I’m going to be doing this in my Azure Developer CLI infrastructure deployment, I think it best if I write a separate post about configuring custom domains.

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