AWS CSA
  • Introduction
  • 1. AWS Overview
    • 1.1 AWS global Infrastructure
    • 1.2 Networking and Content Delivery
    • 1.3 Computing
    • 1.4 Storage
    • 1.5 Databases
    • 1.6 Migration Services
    • 1.7 Analytics
    • 1.8 Security and Identity
    • 1.9 Management Tools
    • 1.10 Application Services
    • 1.11 Developer Tools
    • 1.12 Mobile Services
    • 1.13 Desktop and App Streaming
    • 1.14 Artificial Intelligence
    • 1.15 Messaging
  • 2. IAM - Identity Access Management
    • 2.1 IAM Introduction
    • 2.2 IAM Labs
    • 2.3 Create a billing alart
    • 2.4 IAM Conclusion
  • 3. S3 - Simple Storage Service
    • 3.1 S3 Introduction
    • 3.2 S3 Labs
    • 3.3 Version Control Labs
    • 3.4 Cross Region Replication
    • 3.5 Life Cycle Management
    • 3.6 CloudFront
    • 3.7 CloudFront Labs
    • 3.8 S3 Security and Encryption
    • 3.9 Storage Gateway
    • 3.10 Snowball
    • 3.11 Snowball Labs
    • 3.12 S3 Transfer Acceleration
    • 3.13 Create a static web page using S3
    • 3.14 Storage Summary
  • 4. EC2 - Elastic Compute Cloud
    • 4.1 EC2 Introduction I
    • 4.2 EC2 Introduction II
    • 4.3 EC2 Lab 1
    • 4.4 EC2 Lab 2
    • 4.5 Security Groups Lab
    • 4.6 Upgrade EBS Volume Types - Lab1
    • 4.7 Upgrade EBS Volume Types - Lab2
    • 4.8 RAID, Volumes & Snapshots
    • 4.9 Create An AMI - Lab
    • 4.10 AMI's EBS Root Volumes vs. Instance Store
    • 4.11 Elastic Load Balancer & Health Check - Lab
    • 4.12 CloudWatch EC2 - Lab
    • 4.13 The AWS Command Line & EC2
    • 4.14 Using IAM Roles with EC2
    • 4.15 S3 CLI & Regions
    • 4.16 Using Bootstrap Scripts
    • 4.17 EC2 Instance Metadata
    • 4.18 Launch Configurations & Auto Scaling Groups
    • 4.19 EC2 Placement Groups - Exam Must Know
    • 4.20 Elastic File System (EFS) Lab
    • 4.21 Lambda Concepts
    • 4.22 Build A Serverless Webpage Using API Gateway & Lambda
    • 4.23 Use Polly to Pass Your Exam - Lab of a Serverless Application
    • 4.24 Use Polly to Pass Your Exam - Lab of a Serverless Application
    • 4.25 EC2 - Summary & Exam Tips
  • 5. Route53
    • 5.1 DNS 101
    • 5.2 Route53 - Register A Domain Name - Lab
    • 5.3 Setup Our EC2 Instances - Lab
    • 5.4 Routing Policies - Lab
  • 6. Databases on AWS
    • 6.1 Databases 101
    • 6.2 Launching an RDS Instance - Lab
    • 6.3 RDS - Backups, Multi-AZ & Read Replicas
    • 6.4 DynamoDB
    • 6.5 Redshift
    • 6.6 ElastiCache
    • 6.7 Aurora
    • 6.8 Database Summary
  • 7. VPC
    • 7.1 VPC Overview
    • 7.2 VPC Lab - Part 1
    • 7.3 VPC Lab - Part 2
    • 7.4 NAT Instances & NAT Gateways
    • 7.5 Network Access Control Lists vs. Security Groups
    • 7.6 Load Balancers & Custom VPCs
    • 7.7 VPC Flow Logs
    • 7.8 NATs vs. Bastions
    • 7.9 VPC End Points
    • 7.10 VPC Clean Up
    • 7.11 VPC Summary
  • 8. Application Services
    • 8.1 SQS - Simple Queue Service
    • 8.2 SWF - Simple Workflow Service
    • 8.3 SNS - Simple Notification Service
    • 8.4 Elastic Transcoder
    • 8.5 API Gateway
    • 8.6 Kinesis 101
    • 8.7 Kinesis Streams Lab
    • 8.8 Application Services Summary
  • 9. White Paper Reviews
    • 9.1 Overview of AWS
    • 9.2 Overview of Security Processes - Part 1
    • 9.3 Overview of Security Processes - Part 2
    • 9.4 Risk & Compliance Whitepaper
    • 9.5 Storage Options in the Cloud Whitepaper
    • 9.6 Architecting For The Cloud Best Practices Whitepaper
  • 10. Well Architected Framework
    • 10.1 Introduction of Well Architected Framework
    • 10.2 Pillar One - Security
    • 10.3 Pillar Two - Reliability
    • 10.4 Pillar Three - Performance
    • 10.5 Pillar Four - Cost Optimization
    • 10.6 Pillar Five - Operational Excellence
    • 10.7 Well Architected Framework - Summary
  • 11. Additional Exam Tips
    • 11.1 Exam Tips Based On Student Feedback
    • 11.2 Consolidated Billing
    • 11.3 AWS Organizations - Lab
    • 11.4 Cross Accounts Access
    • 11.5 Resource Groups & Tagging
    • 11.6 VPC Peering & ClassicLink
    • 11.7 Direct Connect
    • 11.8 Security Token Service
    • 11.9 Active Directory Integration
    • 11.10 Workspaces
    • 11.11 ECS - Part 1 - What is Docker
    • 11.12 ECS - Part 2 - What is ECS
    • 11.13 CloudFormation - A Brief Introduction
    • 11.14 Step Functions - A Brief Introduction
  • 12. Practice Tests Questions Summary
    • 12.1 Whizlabs - Free Test
    • 12.2 Whizlabs - Diagnosis Test
    • 12.3 Whizlabs - Practice Test I
    • 12.4 Whizlabs - Practice Test II
    • 12.5 Whizlabs - Practice Test III
    • 12.6 Whizlabs - Practice Test IV
    • 12.7 Whizlabs - Practice Test V
    • 12.8 Whizlabs - Practice Test VI
    • 12.9 Whizlabs - Practice Test VII
    • 12.10 Whizlabs - Section Tests - Part 1
    • 12.11 Whizlabs - Section Tests - Part 2
    • 12.12 Udemy - Final Quiz
  • 13. The Real World - Creating a fault tolerant Word Press Site
    • 13.1 Getting Setup
Powered by GitBook
On this page

Was this helpful?

  1. 5. Route53

5.1 DNS 101

Previous5. Route53Next5.2 Route53 - Register A Domain Name - Lab

Last updated 5 years ago

Was this helpful?

DNS is used to convert human friendly domain names into an Internet Protocol address. IP addresses are used by computers to identify each other on the network.

VPC now is IPv6 compatible.

Top level domain names: .com, .edu, .gov, etc. These top level domain names are controlled by the Internet Assigned Numbers Authority (IANA) in a root zone database which is essentially a database of all available top level domains.

Second level domain names: .com.cn, .com.uk, etc

Domain Registrars: because all of the names in a given domain name have to be unique there needs to be a way to organize this all so that domain names aren't duplicated. This is where domain registrars come in. A registrar is an authority that can assign domain names directly under one or more top-level domains. These domains are registered with InterNIC, a service of ICANN, which enforces uniqueness of domain names across the Internet. Each domain name becomes registered in a central database known as the WhoIS database. Some famous domain registrars such as GoDaddy.com and so on.

SOA (start of authority) Records: The SOA record stores information about:

  • The name of the server that supplied the data for the zone.

  • The administrator of the zone.

  • The current version of the data file.

  • The number of seconds a secondary name server should wait before checking for updates.

  • The number of seconds a secondary name server should wait before retrying a failed zone transfer.

  • The maximum number of seconds that a secondary name server can use data before it must either be refreshed or expired.

  • The default number of seconds for the time-to-live (TTL) file on resource records.

NS Records: NS stands for Name Server records and are used by Top Level Domain servers to direct traffic to the Content DNS server which contains the authoritative DNS records. What essentially happens is when you create a zone in Route53, you are going to given a lot of different NS records, you then have to take these records to your domain registrar, so using GoDaddy for example, you will go into the GoDaddy console, but essentially what you do is you take those records and you supply your domain registrar with these NS records and then in that way traffic will be directed over to Route53. Now recently, Amazon has become a domain registrar and it makes it a lot easier for you because previously you'd have to go through and use ike GoDaddy registered domain name and then basically you would have to go to create the zone in Route53, get all the NS records then update GoDaddy with DNS records in order to get this to work. But now it's all integrated into the AWS console. We can just use AWS as our domain registrar.

A records: An "A" record is the fundamental type of DNS record and the "A" in A record stands for "Address". The A record is used by a computer to translate the name of the domain to the IP address. It is important to understand that an Elastic Load Balancer never has a IP address, ELB always just have a DNS name. So you could not use A record to resolve to an ELB. What we actually use is Alias record.

TTL: The length that a DNS record is cached on either the Resolving Server or the users own local PC is equal to the value of the "Time To Live" in seconds. The lower the time to live, the faster changes to DNS records take to propagate throughout the Internet. When you do a DNS migration, set the TTL to a lower value, say 300 seconds, so that the request will not be sent to old sites.

CNAMES: A Canonical Name (CName) can be used to resolve one domain name to another. For example, you may have a mobile website with the domain name "" that is used for when users browse to your domain name on their mobile devices. You may also want the name "" to reolve to this same address.

MX Records (Mail Exchanger Record): Route53 also support MX Records.

Exam Tips:

  • ELB's do not have pre-defined IPv4 addresses, you are not given a IP address when you create a ELB, you are always given a DNS end point, so you always resolve to ELB using a DNS name. That can cause problems because if you have got "acloud.guru" which is a naked domain name, you always need a IP address to resolve that domain name too. So what Amazon do? They just created Alias records. So Alias records allow you to resolve a naked domain name which is sometimes referred to as the zone apex record to a ELB's DNS address and that's where you are going to see Alias records most commonly used.

  • Understand the different between an Alias Record and a CNAME. The different is that when you are making a request to Route53 for a DNS record you are going to be charged for that request if you using CNAMES. However, if you are making a request and it is an Alias record, you won't be charged. For that reason, when you go into the exam and you read through these scenario questions it will ask you that should you use an A record here or should you use a CNAME here or should you use an Alias record. Most of time you want to choose an Alias record, because you don't get charged for it, and it does allow you to map your naked domain name back to an ELB.

  • Given the choice, always choose an Alias Record over a CNAME.

  • There are only 50 domain names available by default, however it is a soft limit and can be raised by contacting AWS support.

  • Route53 currently supports the following DNS record types:

    • A (address record)

    • AAAA (IPv6 address record)

    • CNAME (canonical name record)

    • MX (mail exchange record)

    • NAPTR

    • NS (name server record)

    • PTR

    • SOA (start of authority record)

    • SPF

    • SRV

    • TXT (text record)

Alias Records: This term is created by Amazon, so only be used in AWS and Route53. Alias records are used to map resource record sets in your hosted zone to Elastic Load Balancer, CloudFront distribution, or S3 buckets that are configured as websites. Alias records work like a CNAME record in that you can map one DNS name to another target DNS name. Key difference - A CNAME cannot be used for naked domain names (zone apex record, i.e. the naked domain name means the domain name without any prefix such as www). Your naked domain name must be an A record. You cannot have a CNAME for naked domain names (like ""), it must be either an A record or an Alias. Alias record sets are supported only for DNS record types A and AAAA. Alias record automatically map your naked domain name or use zone apex domain name to an ELB and that's where it's most commonly used (i.e. Alias Target is the domain name of your ELB). Alias resource record sets can save you time because Amazon Route53 automatically recognizes changes in the record sets that the alias resource record set refers to. It's just an easy way of mapping your naked domain name to an ELB, and this is most commonly used in production.

http://m.acloud.guru
http://mobile.acloud.guru
http://acloud.guru