dns on Alperen Doc

route-53-hosted-zones

Mon, 01 Jan 0001 00:00:00 +0000

Route 53 Hosted Zones#

So far in this course, every time we’ve needed to communicate with an AWS resource we set up, we’ve identified it in one of two ways:

A raw IPv4 address, like we used to load the web app, or to SSH into EC2 instances.
An AWS-provided domain name, like patientping-db.random_id.us-east-1.rds.amazonaws.com for an RDS instance.

But usually for a real company, we need to bring our own domain name and point it to AWS resources.

aws-a-records

Mon, 01 Jan 0001 00:00:00 +0000

A Records#

DNS records tell the world where your domain points to. The most fundamental type of record is the A record.

An A record (i.e., Address record) maps a domain name to an IP address. It’s the most common type of DNS record.

When someone looks up www.ulutasalperen.com, their DNS resolver will ultimately find an A record with the IP address of that site’s server.

Try it yourself with the dig command line tool: dig www.ulutasalperen.dev. It’s useful for troubleshooting, and using it can teach you a lot about DNS.

dns-ttl-and-caching

Mon, 01 Jan 0001 00:00:00 +0000

DNS TTL and Caching#

When you update a DNS record, the change doesn’t appear everywhere immediately. DNS is eventually consistent and heavily cached.

“Eventually consistent” means changes are applied, but not everywhere at once. It takes time to propagate.

When creating DNS records, you’ll notice a field called TTL (Time To Live). This tells resolvers how often to re-check a record. If our records change often, clients need a lower TTL.

The trade-off is always the same: lower TTL means faster updates but more queries (and more cost). Higher TTL means slower updates but fewer queries.

aws-verifying-dns

Mon, 01 Jan 0001 00:00:00 +0000

Verifying DNS#

We have a www.patientping.internal domain name, but it’s only accessible within our VPC.

In other words, this command won’t produce a meaningful IP address locally:

dig www.patientping.internal +short

but if you run that command from the patientping-web-v2 EC2 instance (that’s inside the VPC), you should be able to resolve the domain name!

ssh patientping
dig www.patientping.internal +short
# 10.0.10.50

Example#

Verify that www.patientping.internal resolves from inside patientping-web-v2 over SSH.

SSH into your app server:

ssh patientping

Install dig (if not already installed):

sudo dnf install bind-utils

Run DNS lookup from the server:

dig www.patientping.internal +short

Confirm the command returns 10.0.10.50.
Exit the server:

exit

aws-cname-records

Mon, 01 Jan 0001 00:00:00 +0000

CNAME Records#

What if you want dev.ulutasalperen.com to point to the same server as blog.ulutas.com? You could create another A record pointing to the same IP address, but there’s a better way: CNAME records.

A CNAME record (Canonical Name) maps one domain name to another domain name. It’s kind of like a DNS-level redirect (or more accurately, an alias).

When someone looks up dev.ulutasalperen.com, the CNAME says: “Check blog.ulutasalperen.com instead.” That domain’s A record then provides the IP address.