How to Update DNS Records

What is a DNS Record?

DNS records are text-based instructions that are stored on DNS servers and provide information about a domain name. They are used to map a domain name to an IP address or other data, and to tell domain name servers how to handle traffic to domains and subdomains.

What are the Parts of a DNS Record?

A Record – Maps a domain name to an IPv4 address (the hosting IP address)

In the above example you will see there Type is A, Host is wstrickland.com the value is the IP address for the hosting for that site

AAAA Record – Maps a domain name to an IPv6 address (if the hosting IP address is provided in IPv6 format, this is not common practice)

In the above example there is not an AAAA record listed.

CNAME – Creates an alias from one domain name to another (ex. www.website.com redirects to website.com)

In the above example the CNAME redirects the domain if the user enters www.wstrickland.com to wstrickland.com

MX Record – Directs emails to the appropriate mail servers

In the above example there is no mx record as there is not email set up for this domain.

TXT – used to store information for domain verification or security.

In the above example the TXT record is explaining that even though the domain was purchased through KnownHost, NameSilo is the domain registrar for the domain.

NS – Name Servers – Most domain registrars keep the Name Servers seperate from the DNS record because changing the name servers can cause issues as it redirects ALL control from the domain to the ns assigned. Make sure you REALLY want to change the nameservers before you do this! (See below “When do you change the NameServers“)

On KnownHost you’ll see that the Name Servers are in the right menu.

PTR Record – This is used for reverse DNS lookups or to make an IP address to a domain name.

SRV Record – If this is listed DON’T CHANGE IT! It specifies the hostname and port of the servers for specific services (if they are using multiple servers)

When do you change the NameServers?

You should change the nameservers when you want to delegate DNS management to a new DNS provider or service. This usually happens in the following scenarios:

1. Moving to a New Hosting Provider with Its Own DNS Management
   • Example: If you’re moving from one web host to another (e.g., from Bluehost to SiteGround) and the new host requires you to use their DNS management system, you’ll need to change your domain’s nameservers to point to the new provider’s DNS servers.
   • Effect: The entire domain’s DNS is now managed by the new hosting company or DNS provider. This includes not only A records but all other DNS records (MX, CNAME, TXT, etc.).
2. Switching to a Third-Party DNS Provider (e.g., Cloudflare, Amazon Route 53)
   • Example: If you want to use a specialized DNS provider for better performance, DDoS protection, or enhanced DNS features, you’ll need to change the nameservers to point to that provider.
   • Effect: The new DNS provider now controls all DNS settings, so you’ll manage your A records, CNAMEs, MX records, etc., through their platform.
3. Using a Content Delivery Network (CDN) that Requires Custom Nameservers
   • Example: Some CDNs like Cloudflare require you to change your nameservers to integrate their performance and security features.
   • Effect: The CDN takes over DNS management, allowing you to route traffic through their network for faster content delivery and additional protection.
4. Full Domain Transfer or Sale
   • Example: If you transfer a domain to a new owner or need to point it to an entirely new DNS system (for example, when a domain is sold or rebranded), you may need to change nameservers.
   • Effect: The new owner or service will have full control over DNS, and all existing DNS records under the previous nameservers will no longer apply.
5. Managing DNS on a Separate Platform
   • Example: If you prefer to separate DNS management from your hosting provider (e.g., keeping your DNS records on Google Domains while hosting on AWS), you would point your domain to custom nameservers like Google’s nameservers.

What is TTL and what should it be set to?

TTL stands for “Time to Live” (in seconds). Shortening the TTL during migration will speed up the DNS change propagation. You’ll notice in the example above that the TTL is set to 3600 – 7207. That is 1-2 hours.

The ideal TTL setting depends on the use case. Here are common scenarios:

Short TTL (300 – 600 seconds)

• When to use:
  • You expect frequent DNS changes (e.g., during a website migration).
  • You’re testing new DNS settings or configuring failover systems.
• Pros: Faster propagation of DNS changes. If you change an IP address or other DNS settings, they will take effect quickly.
• Cons: Increases the load on your DNS servers because resolvers have to re-query more often.

Moderate TTL (3600 seconds or 1 hour)

• When to use:
  • Your DNS settings are relatively stable, but you may need to make occasional changes.
  • You want a balance between quick propagation of changes and DNS server load.
• Pros: Balances performance and flexibility for changes.
• Cons: Not as fast as shorter TTLs when updating records.

Long TTL (86400 seconds or 24 hours)

• When to use:
  • Your DNS records are very stable, and you don’t expect changes often.
  • The domain is highly trafficked, and you want to reduce DNS server load.
• Pros: Reduces load on DNS servers and speeds up access for users by caching records longer.
• Cons: DNS changes will take longer to propagate (up to 24 hours).

So, What do I update?

Most of the time when updating the DNS record for a site migration you will ONLY want to update the A Record. That will point the site to the new IP that the site is being hosted at. You will want to change the TTL down to 300 (or as low as the hosting will allow) but make sure to adjust that to a higher TTL once the site has propagated.