The Domain Name System (DNS)

This is a Primer on the Domain Name System (DNS), Registrars, Nameservers and DNS records will no longer make your head spin!

The Domain Name System (DNS) is used for naming computers on a network. DNS specifically maps computer DNS names to one or more of that computers IP Addresses.

maps a computers’ IP Address to a computer name within in your companies (or personal domain name). Let’s assume we own the domain “” ()

is the system that “names computers on the Internet”. More specifically, every computer on the Internet has at least one unique IP address, two computers communicating on the Internet use each others IP addresses for the dialog.

Overview of an IP Address

You can think of an IP address kind of like a phone for computers on the Internet. You should also be aware that IP Addresses can be public or private addresses. Example:


Overview of a Domain Name


  1. Search for Domain Name(s)
  2. Register Domain Name (Registrar)
  3. Renew expiration
  4. Set Nameserver for domain
  5. Ensure doman name does not expire without notification


  1. Setup MX records
  2. Setup apex,, *
  3. Set A, CNAME, PTR and SRV records
  4. Public DNS names
  5. Private END names


  1. Map out public and private domain names.
  2. Map out private IP addresses and names

All domain names belong to one specific Domain Name that is registered and controlled by a single company (entity).

You register your domain name with the Registrar. Namecheap is my registrar. Many people use GoDaddy to register domain names, I do not recommend Go Daddy, I found it more confusing than I thought it needed to be.

An IP address contains exactly four octets or 32bits, that can be represented as a “dotted decimal address or something like:” IPv6 addresses are much longer at 128bits but are not represented as dotted decimal, rather as hex.

  • Overview of IP address
  • IP Address to Name Mapping
  • Publicity
  • Public vs. Private Addresses
  • Public vs. Private Names
  • Domain Name Registry
  • Domain Names are Leased through Brokers

  • Top Level Domain (TLD) => .com, .net, .io, and so on …

You don’t really own a Domain Name you are just renting it. And as of now, you have first right of refusal to renew domain names you currently “own”.

If you fail to renew the DNS name it will go through a expiration process, finally back into the available pool of domain names.

  • Choosing Your Regsitrar
  • Choosing a Domain Name

  • Consider recently expired domains

  • Purchase domains?

  • Verify domain name is not black listed

  • Verify Domain Name not black listed

On Fri, May 4, 2018 at 12:58 PM, wrote: Rusty,

The AQ upgrade server is already assigned in AWS with static IP, so we can move the DNS anytime though as you mention it’s probably best to move evening/night and have records permeate overnight.t

Good point. As the transition takes process, all servers and computers are still accessible via the old DNS names OR their IP addresses. Which can be really important if things don’t sync up..

Care is most important in these scenarios:

  1. MX records (email delivery) make sure email is continuously delivered
  2. The main external web server (if that were to change)
  3. External references to old domains. That is: we’ll need to make sure all external references (computers or programs) that currently point to either goesgetter or edenoaks. We’ll want to identify and change any such references if we can find them.

Otherwise, these changes should be pretty safe. As long as we pay really want to ensure the MX records and all “public” accessible

We can leave the alternate subdomains active (goesgetter/edenoaks) and start to move items to as it is ready. Do you know if the SSH certificates in use with USACE and Boswell uploads to would need to be reissued from and updated on the USACE/Boswell side?

  1. You are correct, we can leave the old domains as they are. As matter of fact, goesgetter forever :)..

  2. Good question regarding certificates… I will need to verify, however, if the certificates have been issued with the domain name that changes, they will almost certainly need to be regenerated if the host name changes..

If the certificates were generated with IP addresses or we leave the old domains in place, then we may be able to get away with the existing certs (make it not so urgent).

However, the certs should be regenerated since the move to will be permanent.

Cut and Pasted From email to matt and SH folks

Just to clarify on apex domain, this would be for, *, etc?

Sure, the apex domain is:

The question is in how “hostnames” like ‘’ or wildcards * are handled. Contributing to this is what we want to consider the “canonical domain name”.

For example here are two different but common configurations:

  1. Public Web server / Canonical IP address (
  2. CNAME for (alias) for
  3. * maps to (any unmapped hostname resolves to

In this scheme: an unknown host will map to the public webserver.

Alternative mappings:

  1. Public Web server / Canonical IP address points to
  2. may point to a different server (or no server at all).
  3. * all unknown hostnames map to NOT FOUND.

In this scheme, public website is only accessible via

looks like is a japanese company.

Sorry, I used as an abbreviation for

These are the initial subdomains needed in addition to MX records: (AWS SSH upload instance) (AWS AQ NG server) (AWS AQ Web Portal)

we will add the public website to this list: www…

I don’t think we’ll need a subdomain for 3.10 AQ TS, and I think we can just update Web Portal to point to the new NG server when we go to migrate so it will remain the same instance.

Yes, that sounds correct.

Let me know if you’d like my help with any of this, but sounds like you have a good plan to proceed.

I’ll consolidate what we have discussed in this thread and send out the “plan” for everybody to look over.

If you don’t mind, you can handle any modifications on the AQ servers themselves.

I will also plan to document the process well so anybody can handle the changes into the future.. This probably become a SOP…

One other thing we should consider would be creating a private subnet for all internal SH connections (and perhaps utilize “private” DNS records only accessible from Internal computers. This is optional, and does not have to happen during transition.. More on this later…

Thanks for the feedback Matt!