404 Error Could Be Your DNS Cache

Overview

Your DNS cache stores the locations (IP addresses) of webservers that contain pages which you have recently viewed. If the location of the web server changes before the entry in your DNS cache updates, you will be unable to access the site. If you encounter a large number of HTML 404 error codes, you may need to clear your DNS cache. This will force your local computer to request new DNS information from its assigned nameservers rather than pull previously retrieved information from its local resolver cache.

How To Clear Your DNS Cache

The following methods allow you to remove old and inaccurate DNS information that may result in 404 errors.

Windows 8

1. Press Win+X to open the WinX Menu.
2. Right-click on Command Prompt and select Run as Administrator.
3. Type the following command and press Enter:

   ipconfig /flushdns

Windows 7

1. Click the Start button.
2. Enter cmd in the Start menu search field.
3. Right-click on Command Prompt and select Run as Administrator.
4. Type the following command and press Enter:

   ipconfig /flushdns

Windows XP, 2000, or Vista

1. Click the Start button.
2. On the Start menu, click Run....
3. If you do not see the Run command in Vista, enter run in the Search bar.
4. Type the following command in the Run text box:

   ipconfig /flushdns

MacOS 10.7 and 10.8

1. Click Applications.
2. Click Utilities.
3. Double-click the Terminal application.
4. Type the following command:

   sudo killall -HUP mDNSResponder

MacOS 10.5 and 10.6

1. Click Applications.
2. Click Utilities.
3. Double-click the Terminal application.
4. Type the following command:

   sudo dscacheutil -flushcache

Once you clear your DNS cache, your local computer will query its nameservers and begin using newly changed information.

Intro to DNS

The Domain Name System (DNS) is a hierarchical naming system used to organize and identify domains, similar to a phone book. Essentially, DNS translates meaningful domains names to IP addresses for the purpose of locating and addressing networking devices worldwide. For instance, the domain name www.example.com might translate to 198.168.10.65. This makes it much easier to remember URLs and email addresses.

A Records

A records (also known as host records) link a domain, or subdomain, to an IP address.

A records do not necessarily match IP addresses on a one-to-one basis. Many A records correspond to a single IP address where one machine serves many web sites. Alternatively, a single A record may correspond to many IP addresses to facilitate fault tolerance and load distribution.

An A record includes the following fields:

• Host Name:

  
  The domain name.
  
  

• IP Address:

  
  The IP address of the web server hosting the domain.
  
  

• TTL:

  
  "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of 3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing the MX records will take longer.
  

CNAME Records

Canonical name (CNAME) records specify that a domain name is an alias of another domain name.

This helps when running multiple services from a single IP address. For example, an FTP and a web server may be located at a single IP address but running on different ports. Each service would then have its own entry in DNS, such as ftp.example.com and www.example.com.

A CNAME record includes the following fields:

• Host Name or Alias:

  
  The domain name that is being setup to point to another location.
  
  

• URL or Alias For:

  
  The domain name to which the alias points.
  
  

• TTL:

  
  "Time to Live." How long it will take to update the record.
  

When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. The canonical name that a CNAME record points to can be anywhere in the DNS, whether local or on a remote server in a different DNS zone.

For example, if your blog was available at example.blogger.com, you could setup a CNAME to point your domain blog.example.com to the Blogger URL. Your readers would then visit blog.example.com to view your blog.

blog.example.com   CNAME   example.blogger.com

This example record may be read as blog.example.com is an alias for the canonical name (CNAME) example.blogger.com.

MX Records

Mail Exchange (MX) records direct email a domain's mail flow.

Most domains have multiple MX records arranged in order of priority. When someone sends an email message to the domain, the first available server in the priority list handles the message.

An MX record includes the following fields:

• Name:

  
  The name of your domain.
  
  

• Class:

  
  This is always set to IN, which stands for Internet.
  
  

• Type:

  
  For MX records, this is always set to MX.
  
  

• TTL:

  
  "Time to Live." How long it will take to update the record.
  
  

• Preference or Priority:

  
  The order of preference for mail delivery. Sending servers should try the lowest preference number first, then the next lowest, and so on.
  Data: The host name of the mail server that handles mail for that domain.
  

For instance, if your domain is example.com, your MX records might look like this:

example.com IN MX 86400 1 smtp1a.example.com
example.com IN MX 86400 2 smtp1b.example.com
example.com IN MX 86400 3 smtp2a.example.com
example.com IN MX 86400 4 smtp2b.example.com

TXT Records

A TXT-record provides the ability to associate some arbitrary and unformatted text with a host or other name. They are often used to establish SPF records, which are explained in-depth in another blog post [link].

NS Records

Name server records determine which servers will communicate DNS information for a domain. Two NS records must be defined for each domain. Generally, you will have a primary and a secondary name server record. NS records are updated with your domain registrar and will take 24-72 hours to take effect.

SPF Records Explained

Email spoofing, forging an e-mail header to make it appear as if it came from somewhere or someone other than the actual source, has become a world-wide problem. Though it can be legitimate, it is usually fraudulent and often used in spam and phishing emails to hide the origin of the message. We've all received scams via email that appear to be from our bank or from some other well-known sender but obviously aren't. Because core SMTP doesn't provide any authentication, it is easy to impersonate and forge emails.

Sender Policy Framework (SPF) is used as one of the standard methods for fighting spam by helping email systems verify the identity of a message sender. This protocol works by defining TXT records in a domain's DNS zone which can be used to validate legitimate email sources from a domain. The string placed within the TXT record specifies a list of authorized host names and IP addresses that mail can originate from for a given domain name.

More and more email systems are adopting SPF and we've repeatedly seen an increase in email deliverability among our customers who have implemented SPF. If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server.

How SPF Works

SPF records are added the same way as a regular A, MX, or CNAME record. The domain administrator publishes a DNS TXT record with a specific syntax that lists all SMTP servers that are valid to send email messages for your domain name. Then, when an email system that has implemented SPF receives a message, it checks the FROM line of the email message. It queries public DNS to find the appropriate TXT record and parses the appropriate SPF information.

If the message was sent from an authorized SMTP server, the message is stamped with an SPF x-header that indicates the message "passed" the SPF check and the message is delivered. If the message was sent from an SMTP server that is NOT authorized, the message is typically rejected. If the domain owner has not specified an SPF record, the message will be stamped with an SPF x-header that indicates it is “unknown" whether or not the message should be trusted.

Publishing Your Own SPF Record

First and foremost, you have to determine all the servers that send mail for your domain name. This is the most time consuming part of creating an SPF record. The more precise your list of sending servers, the more authoritative your SPF record will be.

Once this entry is placed within the DNS zone, no further configuration is necessary to take advantage of servers that incorporate SPF checking into their anti-spam systems.

Here's a sample SPF Record and explanation of each mechanism used:

v=spf1

This declares that this entry is an SPF version 1 record.

mx

This declares that any servers that have valid mx records associated with your domain.com are valid sending servers.

IP4:

This declares mail can originate from this IP address or network range. You may specify a network range by appending slash notation subnet.

-all

This mechanism typically goes at the end of the SPF record and designates the IP addresses you list are the only acceptable sending IP addresses and that all others are prohibited.

Other Resources

To learn more about using SPF records for more advanced configurations, visit the SPF Project's page on SPF Record Syntax.

If you're looking for shortcuts, there are many online tools help you create an SPF record quickly and easily, such as the Microsoft SPF Record Wizard.