CloudInsidr

Cyber security, infotech

  • Subscribe!
  • Privacy Policy
  • Legal
  • Contact Us

Join us on Twitter: @CloudInsidr

Follow us on Twitter: @cloudinsidr
  • news & alerts
    • events
    • industry analysis
    • industry gossip
    • people
  • cloud, edge & co.
    • AWS
    • administration & orchestration
      • web servers in the cloud
      • mail servers
      • databases
  • cybersec & warfare
    • encryption
  • blockchain
Home cloud, edge and everything in between A quick guide to a solid DNS configuration using AWS Route 53 (and how to configure DNS using any other DNS service)
A quick guide to a solid DNS configuration using AWS Route 53 (and how to configure DNS using any other DNS service)

Anna E Kobylinska 2018-08-23 Leave a Comment

A quick guide to a solid DNS configuration using AWS Route 53 (and how to configure DNS using any other DNS service)

The most difficult thing about configuring the DNS settings for a domain is designing a plan of action: making up one’s mind about what kind of services you envision and how you want to route the traffic. Here’s a primer on how to configure DNS using Route 53 or any other service.

Step 1. Sign in to the AWS Management Console in your web browser

In your web browser, sign in to the AWS Management Console.

IMPORTANT: Always use MFA (multi-factor authentication) for your IAM credentials. Always use IAM credentials instead of your AWS root account access (except where required otherwise). An IAM login uses a different URL that might include your AWS account number or an alias of your own choosing (you can set it up this link in the AWS Management Console while signed in with your root account credentials).

Step 2. Navigate to Route 53 and view records sets

From the Services menu, navigate to Route 53. In the Route 53 dashboard, switch to the view of your Hosted Zones. Add a new hosted zone for the domain name you want to configure.

If the hosted zone for the domain name you want to edit already exists, select it and click on the button Go to Records Sets at the top of the page (alternatively, you can click on the count of existing records sets in the right-hand pane).

Step 3. Register your name servers with the registrar of your domain name

When a new Hosted Zone is created, Route 53 automatically generates the obligatory SOA entry as well as an NS record with four name servers supplied by AWS. Make sure that these four name servers are registered as authoritative name servers for your domain with the registrar of your domain (this is the company whose service you used to register your domain name).

Step 4. Create or edit records

The records you need depend on the services you run.

These are the DNS records needed to run a web server:

  • an A record pointing from the domain name to the (external, public) IPv4 address of your web server (the EIP);
  • a CNAME record (typically www) pointing from the host name to the A record,
  • an optional IPv6 record corresponding to the A record.

To run a mail server, create a record of the type “MX — Mail exchange” and enter the host name of your mail server (on this or on another domain) with the default priority of 0 in the form:

0 smtp.somefancymailserver.tld.

However, you will also need a reverse DNS record, which only Amazon can set up for you. For more details, see this post: How to set up a mail server on AWS EC2 using open source software.

Decide how to handle the IPv4 scarcity

Make sure that the IP address(es) in your A record have been assigned to the host that is running your web server. Users of AWS EC2 have to choose how to handle the IPv4 scarcity and the resulting AWS restrictions.

There are several strategies to deal with IPv4 on AWS:

  • use an EIP address (not an automatically assigned public address). The upside: ease of use as the address persists across reboots (there is no charge for the first EIP on each running instance). The downsides: high cost and an IPv4 limit per account.
  • use ELB (Amazon’s Elastic Load Balancer) and you won’t need an EIP.
  • use a dynamic DNS provider to update your DNS configuration each time the IP address changes. (You can set the TTL as low as 5 seconds, by the way.) The downside: DNS and browser caching will cause delays. This method is not recommended for production servers, especially facing the Internet.
  • use a script to update Route 53 each time the IPv4 of an instance changes.
    • Create an instance role with permissions to update Route 53. This role can be limited to only one host name, but must be applied each time a new instance is launched.
    • Save a script somewhere in /home/ec2-user with roughly this content and save it as dnsupdate.sh.
    • Set your script up to run on every instance upon startup (crontab -e):
      • @reboot /home/ec2-user/dnsupdate.sh >dnsupdate.log 2>&1
  • use IPv6 only (not a good idea when serving the public).
  • put your instance behind a proxy such as HA proxy or NGINX and have it forward traffic to your instance’s private IP or internal DNS hostname (both of which won’t change on reboot).

Wait for changes to propagate

You may need to wait a few minutes for the changes to propagate (depending on the previously defined TTL). Tip: when you anticipate the need to make adjustments to your DNS configuration, you may want to reduce the TTL in advance.

TIP: Make sure that the ports that your service uses (typically 80 for http and 443 for https) are not being blocked by any firewalls or the AWS Security Group.

Step 5. Verify your DNS configuration (and modify settings if required)

Verify that the settings are correct by using a diagnostic service such as intodns.com. Enter your domain name and run the test.

(Should you receive an error as a result of a missing MX record, you can safely ignore it as it does not affect your ability to run a web server; it is only needed if you also happen to require a mail exchanger such as Postfix.

Step 6. Configure your web server software for the IP address and the hostname

Make sure that your web server software knows that it should listen on the network interface that corresponds to the public IP address that will be receiving incoming traffic on open ports. Make sure that the web server feels responsible for serving documents for its host name. Here is a post on how to set up NGINX.

Filed Under: cloud, edge and everything in between, cybersecurity and cyber warfare Tagged With: AWS, DNS, EIP, IPv4, MFA

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Subscribe

SSL/TLS Certificate Square (250 x 250)

Pearson Education (InformIT)

SSL/TLS Certificate Medium Rectangle (300 x 250)

Recent Posts

  • Upgrading from CentOS 6 to CentOS 7 and Beyond?
  • How To Figure Out Who is Signing In To Dovecot to Send or Retrieve Email
  • OpenSSH 9.9 Introduces Enhanced Quantum-Resistant Algorithms
  • OpenSSL 3.3 Final Release is now live!
  • How to Activate HTTP/2 with TLS 1.3 Encryption in NGINX for Secure Connections without a Performance Penalty
  • Is AWS sucking your budget dry? Strip it down to the nitty-gritty (without breaking stuff)
  • How to attach and mount an NVMe EBS volume on EC2
  • SELinux security contexts: correcting SELinux labels on a file system
  • Intel gobbling up Israeli Tower Semiconductor, Stock Goes Through The Roof
  • NGINX on AWS EC2: setting up a web server from scratch on a domain of your choice
  • Log4j RCE and mitigation techniques
  • Set up logrotate for Postfix

Symantec

Categories

  • administration and orchestration
  • alerts
  • AWS
  • Bitcoin
  • cloud, edge and everything in between
  • cryptocurrencies
  • cybersecurity and cyber warfare
  • databases
  • DNS
  • encryption
  • events
  • FinTech and InsurTech
  • homeland security
  • HTTP Security Headers
  • industries
  • industry analysis
  • industry gossip
  • Java
  • Linux
  • mail servers
  • networking
  • news
  • NGINX
  • people
  • php-fpm
  • reviews
  • SELinux
  • tips and tricks
  • Uncategorized
  • web servers in the cloud

Tags

AMI AWS AWS EBS Azure certificate cipher suites cryptography cyber defense cybersecurity cyber security Diffie-Hellman DNS DNS over HTTPS Dovecot EBS EC2 email encryption Fedora HTTP/2 HTTPS IBM letsencrypt Linux logs MariaDB MFA MySQL NGINX OpenSSL permissions php-fpm PHP 7 postfix RegEx Route 53 RSA SELinux SQL SSH SSL TLS TLS 1.3 TLS vulnerabilities WordPress

Archives

  • January 2025
  • November 2024
  • October 2024
  • May 2024
  • January 2023
  • March 2022
  • February 2022
  • December 2021
  • December 2020
  • November 2020
  • September 2020
  • January 2020
  • November 2019
  • August 2019
  • July 2019
  • April 2019
  • December 2018
  • October 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • February 2018
  • December 2017
  • November 2017
  • October 2017
  • August 2017
  • April 2017
  • February 2017
  • January 2017
  • November 2016
  • September 2016
  • August 2016
  • July 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • July 2015
  • February 2015

Recent Comments

    Wicked fast Networking (With a Government Clearance to Boot)

    ©2022 CybrAnalytiqa OÜ

    • Content purchasing and syndication