Dealing with DNS

At its inception the Internet was used solely by computer geeks and techies. Today the web has grown to become something we use on a daily basis. It's amazing how quickly the Internet went from obscurity to becoming something we take completely for granted. We hardly give a second thought to how this incredible system works.

Behind the scenes however, there are technical processes that make email and websites work. While some of us are curious enough to explore the inner workings, I imagine most don't particularly care, as long as it keeps working. However, when building a website, questions about hosting must come up. Having a working knowledge of the key aspects of how hosting works can help avoid problems stemming from hosting related issues.


Hosting email and hosting a website are actually two very different things. It is common for Internet Service Providers (ISPs) to host both a website and email. It makes sense to bundle these two related services, but in reality the underlying technology for hosting a website and hosting email are completely distinct from each other. Since they are usually purchased together, combined in one hosting plan, we tend to think of them as the same thing.

The ultimate point of commonality between hosting a website and hosting email is the domain name. The domain is the main part of a website address that follows the "www." They are also the part of an email address that follows the "@" symbol. Domain names include the ".com" or ".net" etc. of the address. Therefore newfangled.com and newfangled.net are completely different domain names.

The key to understanding the difference between hosting a website and hosting email is in understanding how domain names work. We've already stated that hosting a website and hosting email are actually two very different services. In fact there is a third kind of hosting that is also distinct from, but related to, web and email hosting, that is, domain name hosting.


Before a website can be hosted, or email set up, a domain name must be registered. Registering a domain name used to be something only one organization (Internic) was authorized to do. Today you can register a domain name through many different services. Some popular registrars are www.netsol.com (Network Solutions - now owned by VeriSign), Register.com (www.register.com), and Go Daddy (www.godaddy.com). These services look up domain names to see if they are available. Domain name registrations typically cost between $10 to $35 annually. Purchasing a domain name simply means that you own it. To use it for anything like email or a website, the domain name itself first needs to be hosted. The default is usually to have the domain registrar, Network Solutions for example, host the domain, but this is not required. Anyone that maintains a domain name server (more on DNS servers later) can host the domain. Before you can get a website or an email account working with the domain you have to decide where the domain name is going to be hosted. All three aspects of hosting; domain name, website, and email can be hosted by completely different service providers.

When people inquire about "website hosting" they usually group all three elements together, or more accurately, they fail to recognize that there are three different things that need to be hosted.


Of all three elements it is the domain name hosting itself that holds it all together for the smooth operation of the others. Some clients don't realize that the company hosting their website may not be the same company that's hosting their domain name. Frequently, the company that originally registered the domain name continues to host it. Register.com, for example, offers domain name hosting as an additional service to purchasing a domain name. If you have ever purchased a domain you may remember that one step in the process allows you the option of providing a primary and secondary DNS (domain name server) name or IP address. This DNS name (or number) is how you would tell Register.com who will host the domain name itself. Register.com and other similar services assume that most people who register domains don't understand this distinction and so they default to using their own DNS servers for the domains they register. This makes it easier to register a domain, but can also make it harder to make changes to the domain name records later because years later people forget who they registered with, and they lose track of the account information (user and password) they used when originally registering the domain name. Additionally, many companies will have a third party do their domain name registration for them. This adds another layer of obfuscation to gaining access to the domain registration account.


If a third party registered a domain, it is possible that when they registered it they assigned the domain to themselves. If this is the case then technically and perhaps legally they own the domain name. Sometimes this happens out of ignorance or for convenience and the third party will cooperate in re assigning the domain to the client - but if they aren't there could be a real fight for ownership of the domain. This can, without saying, put a crimp in the "go live" process.

Once access to the domain's account is gained, changes to any aspect of hosting can be made to the domain's records.

Modifying domain name records is technically an easy thing to do. Getting access to the domain records in order to change them can be quite difficult. Domain name records are used to "point" requests for a website or requests to send email to their corresponding hosting services. For example, each domain name includes a "www" record. As you might guess this record points to the server hosting the website for that domain. The domain name also has something called an "MX" record. The MX record points to the email server for that domain. If the records within the domain name are absent or incorrect the website or email addresses will not be found. To change the hosting of a website or email service the domain name records will have to be modified.


In addition to making changes to specific domain name records it sometimes makes sense to assign the domain name itself to a new DNS server that IT staff or a web developer can access.

Snags can occur when moving a domain name. The transfer of a domain from one DNS server to another requires the approval of the administrative contact listed for the domain. Typically this is done through an email approval process. The administrative contact receives an email noting the requested transfer, and must reply from the email address listed in the domain's record with approval. Sometimes the administrative contact is either not at the company anymore, or the original email address they used to register the domain is no longer active. In either event a cumbersome, time consuming process may have to take place to reassign the administrative contact manually.

Unfortunately these kinds of snags are often overlooked until just before a site is supposed to go live. The potential delays can be extremely frustrating. This is why we try to uncover the status of a company's domain name at the earliest possible opportunity when staring a project.


Figuring out the best scenario for hosting the three elements (domain name, website and email) is usually determined on a case-by-case basis. In some cases we host all three aspects in others we may only host the website itself. Email is one of the key factors in deciding who will host each piece. Many companies host their own email. When this is the case we simply need to point the domain's MX record to the company's internal email server. If the company also hosts their own domain name we will usually have them point the domain's www record to our web server. If they don't host their domain we usually will look into moving the domain to our DNS server on RackSpace and then point the email (MX) record back to the company's email sever. Whatever structure is ultimately best, modifications to the DNS records are necessary.

One of scariest moments in making a site live is making the changes to the DNS records. Because these records ultimately point the whole world to the email and website related to the domain name, a mistake can completely "break" access to the site and email. Because of the way modifications are implemented, if a mistake is made there is no instant way of fixing it. This is because of how domain name servers work.

There are millions of DNS servers in the world. Anyone can set up a DNS server, we have one through RackSpace. Every DNS server contains a long list of every domain name in the world and their corresponding records. These DNS servers have to keep track of lots of information. Domains change all the time and so DNS servers must update themselves frequently. How frequently? That's the kicker. It's up to the system administrator who runs the DNS server. Some update every few hours and others perhaps daily. Therefore, when a change is made to a DNS record it may take a day, or sometimes two, for all the DNS servers to update themselves, thus making the change complete. During this time some DNS servers will point to the new server, and others that haven't been updated will point to the old server. One effect of the DNS update process is that it is entirely possible for users in one part of the world to be accessing an updated DNS server so that they see the new site, while others who access an un-updated DNS server may still be directed to the older site's server.

Because of the way DNS records are updated mistakes can be costly. If the www records or the email records are not modified correctly (misspelling of a domain, or accidentally transposing numbers in an IP address) the new modification will result in updating all the DNS servers with the wrong information so that the website will not be found, and email bouncing. Correcting the record itself can be done very quickly, but the correction won't fully take affect for a day or more.

Additionally, because there is usually more than one party involved in DNS modifications, and information between these parties can sometimes be misunderstood or incorrect, problems with DNS modifications are not uncommon. And again, the more parties that are involved the more delay there can be in making domain record modifications.

Being aware of the problems is the first step in avoiding them. There are other things we can do to keep hosting issues from becoming last minute disasters.

Get the technical contacts to talk to each other directly. If we can get the technical contact at the client to discuss these issues with our system administrator early on in the process, we can usually discover and address all these issues before they become problems. If the two technical contacts work together during the DNS modification stage, errors are less likely to occur. Our agency partners can be helpful in this regard by simply making inquiry into who the technical contact is and making the proper introductions.

Never schedule a website launch on a Friday. Because there are so many technical details (and risk of error) we do not plan "go live" dates for the end of the week. This is because, if there are going to be problems when DNS modifications are made, we want to be here to address them right away. Otherwise an entire weekend can go by before we can fix a problem. Scheduling a launch for a Monday or Tuesday is ideal.

Lookup the domain name and confirm the accuracy of the administrative contact information before beginning the project. By going to www.netsol.com and clicking on the "whois" link in the upper right hand corner of the page you can look up a current DNS record. This information will tell you who is hosting the domain name as well as listing the administrative contact. Check with your client that the email address listed for the administrative contact is still active. It can also be helpful if the client still has their account number and password from when they registered their domain. If they do not, you may want to have them request this information from the company that's hosting their domain.

Ask about email. If your client hosts their own email there should be few problems. If they are using their current web hosting for email, we will need to look into other options. If they do not yet have email through their domain we have several possible avenues to explore. In general it is much easier to establish something new, than changing something that is currently being used.


With proper attention, and by following these guidelines we can make the hosting aspect of web development as smooth as possible for your clients. Having this information available and being proactive about asking these questions will demonstrate to your client that you are on top of the project and looking out for their best interest. As always we are available to help you answer these questions to keep projects running smoothly.