DNS – An Introduction

Though you may not know it, DNS (Or Domain Name System) is probably the most used things on the Internet. In fact, you’re using it right now. For those who don’t know what DNS is or does, it is the system we use to translate Domain Names to IP Addresses.

The World Before DNS

Back in the early days of the Internet (And by early, I mean before it was even *called* the Internet), all of the computers that were connected to one another could only be reached by using a series of numbers. To get to the computer you wanted to access you had to know the right number for it. It was kind of like the modern telephone network, where you have to know the phone number of the person you want to talk to. This being the time before anyone had a really easy way to remember all of the address numbers for the computers they had or wanted to access (aside from writing it all down on a piece of paper), a shortcut was very quickly developed, the HOSTS file.

A HOSTS file is a simple text file that was stored on the computer and allowed people to assign memorable names to the computer addresses they wanted to access. Instead of putting in a number like to access a computer, users just had to put in the name that was assigned to that number. Keeping with the phone comparison, this was similar to having a phone number that, based on the letters assigned to each number on a phone, allows you to say “Call me at 1-555-MYPLACE”. This is both easier to remember and easier to communicate (As a side note, each computer still has a HOSTS file that you can use to assign a specific name to a specific number. In windows, the file is located at C:\Windows\System32\Drivers\Etc\HOSTS. You can play around with that and see what happens if you want. Many IT pranks involve modifying the HOSTS file, so it’s always good to know about it). The problem, though, was that each system had to have its own HOSTS file. So each computer had a completely unique set of data about which words translated to which numbers.

The unique HOSTS file on each computer lead to some issues, specifically it lead to a lot of work filling out the file for each computer you wanted to use, not to mention the problems that may occur when you want to communicate the location of some internet based resource to someone. So after a little while a central “authority” created a publicly available HOSTS file that could be obtained by anyone who didn’t want to fill out their HOSTS file with all the names and IPs they wanted or needed. This was a good short term solution, but after the Internet became “The Internet” (as opposed to its original name ARPANET), the size update frequency of the centralized HOSTS file became too overwhelming. This is when the need for a fully automated method of handling the word to number translation became apparent. Here is where DNS comes in to play.

What DNS Does

DNS was created to allow easy creation, distribution, and update of “Internet Names.” Internet Names are the words that we assign to numbers (IP Addresses). You use DNS every day without realizing it. In fact, you used it to get to this website.

DNS is, put simply, a group of servers that do nothing but maintain and distribute word to number translations (as well as number to word translations, but that piece, known as Reverse DNS, is beyond the scope of this article).

How DNS Works

DNS functions by separating lists of name to number translations in a group of similar names in “Domains”. Each dot in a URL represents a level of authority. For instance, in my blog’s URL, http://www.acbrownit.com, includes four levels of authority, with the authority level becoming more narrow as you move to the left in the URL.

The highest level of authority in a URL starts *before* the .com, with the International Assigned Numbers Authority (IANA). The IANA’s servers represent the core list of DNS records. If you would like to look at the full list of records, you can go to IANA’s website (you can click on each Zone to see the ownership records and servers that hold the database for that zone). Historically, IANA has maintained complete authority over Internet DNS records and was originally maintained by the US government. A few years ago, IANA was spun off into a separate, independent organization without any governmental oversight. About the same time, IANA opened the root DNS zones up to complete customization.

Originally, there were less than 200 root DNS zones, .com, .info, .org, .gov, and zones for each nation (.uk, .aus, .ca for the UK, Australia, and Canada, as examples). There were a few other zones, but IANA kept a pretty strict cap on DNS root zones to ensure that each DNS server on the Internet was capable of storing the entire DNS database, if necessary. Early Internet connected DNS servers had significantly more limitations than modern servers. The average smart watch has several orders of magnitude more processing and storage capacity than the earliest DNS servers, which put significant limits on the number of URLs available. With IANA removing the strict limits on root DNS zones, thousands are now available, including .APPLE (guess who owns that one), .BANANAREPUBLIC, and others. These newer root zones are often referred to as “Vanity” domains.

The COM domain is the next highest level of authority in my URL, and is referred to as a Top Level Domain (TLD). It is owned and maintained by Verisign Global Registry Services. Verisign’s DNS servers hold a list of records called a DNS Zone that points every domain that ends in .com to the authoritative servers used to store the zones for the next level of authority.

The ACBROWNIT domain is the next level of authority. This domain is “owned” by WordPress, but administered by…well, me. I pay a certain amount of money each year to maintain my rights to do whatever I want with the acbrownit.com domain, including move it to a different registrar like Godaddy, Network Solutions, or others, if I want to. WordPress also maintains the servers that provide access to my blog, and I pay a flat rate each year to use both services.

The next level of authority is completely managed by me, and represents what is called a DNS “A record”. “A Records” consist of a name and an IP address. In this case, the name is WWW and the IP address is The IP is tied directly to the network where my blog’s data is stored.

The DNS Lookup Process

DNS lookup occurs according to the below flowchart. Please note, this is a very simplified version and leaves out a number of technical details, but should give you an idea of how things work.

DNS Process

Every computer that has an Internet connection is configured with a DNS Server that acts as their primary point of contact for looking up DNS records. Usually, this service is provided by the company you purchase your Internet connection from. Most Internet Service Providers only allow their own customers to use their DNS servers. There are also a lot of “public” DNS servers that are owned by various companies. Public DNS servers are available to anyone who wants to use them, and most IT guys have at least a few memorized. The most common are owned by Google ( and or Level 3 ( There are a number of sites that provide lists of publicly available DNS servers.

The End of This Post

So that was a lot of information that should help you to better understand how DNS works. Every computer uses it, and without it, the Internet would not be able to function as well as it does. Hopefully, you understand it a little better. You may never give a thought about it again, but it never hurts to know more about how things work. And for those who are just starting a career in tech or are budding hobbyists, this article should give you much needed information that will serve you well in the future.

Stay tuned for the next post on DNS, where I’ll cover some of the more technical parts of the protocol, including record types, how each record type functions, historical weaknesses in DNS that have been and still are exploited to spread malicious software or phishing email, and how you can use DNS to provide a little bit of failover capability to servers.




How Does Exchange Autodiscover Work?

Autodiscover is one of the more annoying features of Exchange since Microsoft reworked the way their Email solution worked in Exchange 2007. All versions since have implemented it and Microsoft may eventually require its use in versions following Exchange 2016. So what is Autodiscover and how does it work?

Some Background

Prior to Exchange 2007, Outlook clients had to be configured manually. In order to do that, you had to know the name of the Exchange server and use it to configure Outlook. Further, if you wanted to use some of the features introduced in Exchange 2003 SP2 and Outlook 2003 (and newer), you had to manually configure a lot of settings that didn’t really make sense. In particular, Outlook Anywhere requires configuration settings that might be a little confusing to the uninitiated. This got even more complicated in larger environments that had numerous Exchange servers but could not yet afford the expense of a load balancer.

The need to manually configure email clients resulted in a lot of administrative overhead, since Exchange admins and Help Desk staff were often required to configure Outlook for users or provide a detailed list of instructions for people to do it themselves. As most IT people are well aware, even the best set of instructions can be broken by some people, and an IT guy was almost always required to spend a lot of time configuring Outlook to talk to Exchange.

Microsoft was not deaf to the cries of the overworked IT people out there, and with Exchange 2007 and Outlook 2007 introduced Autodiscover.

Automation Salvation!

Autodiscover greatly simplifies the process of configuring Outlook to communicate with an Exchange server by automatically determining which Exchange server the user’s Mailbox is on and configuring Outlook to communicate with that server. This makes it much easier for end users to configure Outlook, since the only things they need to know are their email address, AD user name, and password.

Not Complete Salvation, Though

Unfortunately, Autodiscover didn’t completely dispense with the need to get things configured properly. It really only shifted the configuration burden from Users over to the Exchange administrator, since the Exchange environment has to be properly configured to work with Autodiscover. If things aren’t set up properly, Autodiscover will fail annoyingly.

How it Works

In order to make Autodiscover work without user interaction, Microsoft developed a method for telling Outlook where it needed to look for the configuration info it needed. They decided this was most easily accomplished with a few DNS lookups based on the one piece of information that everyone had to put in regardless of their technical know how, the email address. Since they could only rely on getting an email address from users, they knew they’d need to have a default pattern for the lookups, otherwise the client machines would need at least a little configuration before working right. Here’s the pattern they decided on:

  1. Look in Active Directory to see if there is information about Exchange
  2. Look at the root domain of the user’s email Address for configuration info
  3. Look at autodiscover.emaildomain.com for configuration info
  4. Look at the domain’s root DNS to see if any SRV records exist that point to a host that holds configuration info.

Note here that Outlook will only move from one step to the next if it doesn’t find configuration information.

For each step above, Outlook is looking for a specific file or a URL that points it to that file. The file in question is autodiscover.xml. By default, this is kept at https://<exchangeservername>/autodiscover/autodiscover.xml. Each step in the check process will try to find that file and if it’s not there, it moves on. If, by the end of step 4, Outlook finds nothing, you’ll get an error saying that an Encrypted Connection was unavailable, and you’ll probably start tearing your hair out in frustration.

What’s in the File?

Autodiscover.xml is a dynamically generated file written in XML that contains the information Outlook needs to access the mailbox that was entered in the configuration wizard. When Outlook makes a request to Exchange Autodiscover, the following things will happen:

  1. Exchange requests credentials to access the mailbox.
  2. If the credentials are valid, Exchange checks the AD attributes on the mailbox that has the requested Email address.
  3. Exchange determines which server the Mailbox is located on. This information is usually stored in the msExchangeHomeServer attribute on the associated AD account.
  4. Exchange examines its Topology data to determine the best Client Access Server (CAS) to use for access to the mailbox. The Best CAS is determined using the following checks:
    1. Determine AD Site the Mailbox’s Server is located in
    2. Determine if there is a CAS assigned to that AD site
    3. If no CAS is in the site, use Site Topology to determine next closest AD Site.
    4. Step 3 is repeated until a CAS is found.
  5. Exchange returns all necessary configuration data stored in AD for the specific server. The configuration data returned is:
    1. CAS server name
    2. Exchange Web Services URL
    3. Outlook Anywhere Configuration Data, if enabled.
    4. Unified Communications Server info
    5. Mapi over HTTPS Proxy server address (if that is enabled)
  6. Outlook will take the returned information and punch it into the necessary spots in the user’s profile information.

Necessary Configuration

Because all of this is done automatically, it is imperative that the Exchange server is configured to return the right information. If the information returned to Autodiscover is incorrect, either the mailbox connection will fail or you’ll get a certificate error. To get Autodiscover configured right, parts 5.1, 5.2, 5.3, and 5.5 of the above process must be set. This can be done with a script, in the Exchange Management Shell, and in the Exchange Management UI (EMC for 2007 and 2010, ECP/EAP for 2013/2016).

Importance of Autodiscover

With the release of Outlook 2016, it is no longer possible to configure server settings manually in Outlook. You must use Autodiscover. Earlier versions can avoid using it by manually configuring each outlook client. However, before doing that, consider the cost of having to touch each and every computer to properly configure Outlook. It can take 5 minutes or more to configure Outlook on one computer using the manual method, and with Exchange 2013 it can take longer as you also are required to input Outlook Anywhere configuration settings, which are more complex than just entering a server name, username, and password. If you multiply that by the number of computers you might have in your environment and add in the time it takes to actually get to the computers, boot them up, and get to the Outlook settings, the time spent configuring Outlook manually starts to add up very quickly. Imagine how much work you’d be stuck with configuring 100 systems!

In contrast, it usually only takes 10 to 20 minutes to configure Autodiscover. When Autodiscover is working properly, all you have to do is tell your users what their email address is and Outlook will do all the work for you. With a little more configuration or some GPO work, you don’t even have to tell them that!

When you start to look at the vast differences in the amount of time you have to spend configuring Outlook, whether or not to use Autodiscover stops being a question of preference and starts being an absolutely necessary part of any efficient Exchange-based IT environment. Learning to configure it properly is, therefore, one of the most important jobs of an Exchange administrator.