Using a domain for local development in Route53

Using a domain for local development

Sometimes you need to use a real domain for local development instead of localhost. This is especially true when you are working on a project that has the need to use a real domain. For example, if you are working on a project that uses OAut.

Setup

Instead of using the hosts file, a local dns, such as dnsmasq, coredns, bind, etc. in this example we will make use of a domain you have ownership of to point to your local machine.

If you already have a domain, and in our example we will make use ilhicas.com for testing purposes, we will be creating a subdomain for local development. In this example we will use local.ilhicas.com and point it to 127.0.0.1 via a cname.

In our case we will be using Route53 hostedzone to manage our domain. If you are using a different provider, the steps will be similar.

As usual we will also be using Terraform to manage our infrastructure.

Terraform for Route53

Given that we already have a hostedzone, instead of creating a new one, we will be using the existing one and using a data source to get the hostedzone id.

data "aws_route53_zone" "ilhicas" {
  name = "ilhicas.com"
}

So, now we have the hostedzone id, we can create the record for our local development domain.

resource "aws_route53_record" "local" {
  zone_id = data.aws_route53_zone.ilhicas.zone_id
  name    = "local.ilhicas.com"
  type    = "A"
  ttl     = "300"
  records = ["127.0.0.1"]
}

So in the above example, we are creating a new record named local.ilhicas.com and pointing it using an A record to 127.0.0.1 which is the ip of the internal loopback interface for all machines.

This allows you to have a project that you can share across a team and use a real domain for local development.

Testing

So first we must terraform apply to create the record.

terraform apply

Now we can test it by using dig to query the record.

dig +short local.ilhicas.com

Should return

127.0.0.1

Also, be mindful that if you are using a different authorative nameserver, you will need to update the dns records for the authorative nameserver to point to the new record.

In my case this is the case as despite using route53, I am using a different authorative nameserver defined at my registrar to make use of ezoic so that I can serve ads on my site.

Conclusion

Using a real domain for local development has several advantages, especially within the realm of containers and oauth tokens as it allows you to test the full flow of the application.

Using a domain will also allow you to emit certificates with letsencrypt and use them for local development by making use of the certbot tool with the dns challenge, which is something I will be covering in the next post.