Understanding how DNS works in Hyper-V

The last couple of posts in this series have dealt with how Ethernet frames and IP packets get to their destination. In this post, we’ll step up a little bit and look at the role DNS plays in getting those packets to the correct IP address. We’ll see how this works in general and the issues specific to a Hyper-V environment.

• Part 1 – Mapping the OSI Model
• Part 2 – VLANs
• Part 3 – IP Routing
• Part 4 – Link Aggregation and Teaming
• Part 5 – DNS
• Part 6 – Ports, Sockets, and Applications
• Part 7 – Bindings
• Part 8 – Load-Balancing Algorithms

What is DNS?

DNS is a remarkably simple, yet just as remarkably misunderstood technology. I’ve lost track of the number of truly brilliant people I’ve met that struggle with it. So, if you’re confused by DNS, you’re in good company. Let’s see what we can do to get rid of the confusion.

Its usage has expanded over the years, but the basic problem that DNS addresses is that humans are not very good at remembering numbers. We have a comparably good ability to recall words, especially when using associative techniques. Computers, as you’ve probably noticed, have the opposite problem. Not only do they like numbers, they store “words” as numbers. DNS was designed to bridge this gap.

At its core, DNS (domain name system) is a directory that matches names with numbers. That’s about as complicated as it gets. It has a few other functions, but they all boil down to matching a name to a number. There are a couple of common analogies that easily illustrate this concept.

The first is phone numbers. Each phone line has a globally unique number. Remembering more than a few of them is extremely difficult. So, phone directories were created. For most of my life, these directories were manifested in large printed books known as the “white pages”, which first lost ground to basic speed dial, and are now built right into everyone’s smartphone.

The second is physical street addresses. In the U.S., the ZIP+4 alone specifies the exact destination. It’s usually accompanied by a larger, more complicated arrangement that is more human-comprehensible.

Just as those systems match human-decipherable addresses to more specific locations, DNS matches human-readable names to IP addresses. Like the telephone system, it does so in a precisely ordered, hierarchical fashion. This system works from right-to-left. As you work toward the left, each successive element becomes more specific. In a fully-qualified domain name, the left-most object represents the final destination. We’ll work with the Altaro website as an example:

www.altaro.com.

Each element is separated by a dot. In a complete DNS name, a dot does exist at the very right-most position, although it’s usually suppressed. This dot represents the root domain; nothing can be any higher in the hierarchy. This root domain contains all other domains.

www.altaro.com.

Moving to the left, the next object we encounter is “com”. This is known as a top-level domain, which is occasionally abbreviated to TLD. “com” is one of several well-known top-level domains that are available on the Internet. Recently, changes to the public registration system have added quite a number of additional top-level domains. Some of these are protected, like edu and gov. Others are open to registrars to provide naming services to customers.

www.altaro.com.

After “com”, we find another period. The periods are how DNS separates elements, but have no special meaning in any position other than the root domain.

www.altaro.com.

Next, we reach “altaro”. The contents of this element are generally just called the domain. In this case, the company called “Altaro” has registered the domain name of “altaro” underneath the top-level domain of “com”. As the legal registrants, they can put just about anything inside this domain that they like and no one else is allowed to use it.

www.altaro.com.

The next element is “www”. I believe that this particular character string is largely responsible for most of the confusion that people feel when talking about DNS. Because it is the left-most element, it is the most specific part of the entire DNS name. In a traditional fully-qualified DNS name, this would refer to a single computer called “www”. However, since the dawn of the web page, it seems that everyone has a computer called “www” sitting on the Internet, serving up web traffic. It is the ubiquity of computers named “www” that confuse people when you tell them that it is the most specific element of the web name, not the least.

www.altaro.com.

In traditional DNS parlance, the “www” portion is usually called the hostname. Of course, in the modern era, there probably isn’t a computer actually called “www”. It’s probably a hardware load-balancer or a group of computers operating in round-robin or something of the sort. But the point is, “www” is a singular entity that has a specific IP address that is the target of the fully-qualified name “www.altaro.com”.

So, to match it back to the street address analogy, the right-most period means “the world”, “com” means the country, “altaro” is the city, and “www” is the street and house number. To match it to the phone number analogy, the right-most period is again “the world”, “com” is the country code, “altaro” is the area code and prefix, and “www” is the final set of numbers. These analogies are obviously not completely perfect, but the concepts are the same.

DNS becomes considerably easier to understand when you move away from “www”. Another DNS name that’s common to many Internet entities is “support”. For example, “support.microsoft.com” refers to an entity named “support” that is part of the domain “microsoft” that is a member of the TLD “com”.

Confusing Conventions

The usage of “www” isn’t the only way that people trip up over DNS. Another is that we’ve also developed tools, especially web servers and browsers, to reduce the complexity in a way that masks the true operation of DNS. For instance, if you just tell your browser to go to “altaro.com”, you’ll land on “http://www.altaro.com”. Some websites, such as http://sourceforge.net, mask the computer name out entirely. This very common behavior has led people to believe that they are connecting to “altaro.com” and that the “www” is just an optional relic. Even though the actual name of the system you’re connecting to really doesn’t matter, it’s still there and is separate from its containing domain name.

What about https:// and other URL components?

Another stumbling block for many people is the fact that a DNS name is just one part of a uniform resource locator (URL). A fully-qualified DNS name is composed of nothing more than alphanumeric identifiers (hyphens are also acceptable) separated by periods. The other elements of a URL have different purposes and are not part of DNS. The first of these elements that you usually encounter is the protocol identifier, such as “http://”. Other common protocol identifiers are “https://” and “file://”. What these do is identify to the browser (or any URL-friendly application) that it should connect using a specific protocol. As with “www”, “http://” is so ubiquitous that it’s sometimes assumed to be attached to the DNS name somehow.

A complete URL also contains a resource identifier. For example, https://help.altaro.com refers to a resource named “support.php” that is served by the entity named “www” on the domain “altaro” which is a member of the TLD named “com”. Most web sites employ default resources, which means that they automatically serve up a specifically-named entity, such as index.html whenever the client browser doesn’t request a resource. In terms of a web server, such as resource is always delivered in some fashion. For other URLs, such as ldap://dc1.domain.local, just access to the target system may be enough. The important fact for this discussion is that a trailing slash (/) and anything that comes after it is not part of the DNS name.

Subdomains

The above examples are the most common and basic format for a DNS name. The dotted notation can continue to proceed to the left with subdomains. Consider:

chat1.chatnet.socialmediaco.com

The above refers to the entity named “chat1” which is a member of subdomain “chatnet” which is a part of the domain “socialmediaco” which is under the TLD “com”.

Fully-Qualified and not-so-Fully-Qualified

In the early days of DNS, you really only thought about hostnames, domain names, and fully-qualified domain names (FQDN). For an individual host, the first two would combine to form the latter. So, going back to our original example, “www” is the hostname, “altaro.com” is the domain name, and “www.altaro.com” is the FQDN for the “www” host. But, as work was done to simplify even the DNS system for the average user, other things began to be lost. To reuse another example, http://sourceforge.net is missing a hostname. http://intranet is missing a domain name. Any time you see a DNS name that appears to stray from the format shown above, just be aware that it’s likely that you’re looking at a name that is somewhat less than fully-qualified. There are methods employed that take these partial inputs and resolve them into FQDNs. We’ll look at these later.

DNS Server Operation

If you have access to a Microsoft DNS system, I find that DNS is pretty simple to understand just by poking around in the console. Here’s a screenshot of mine:

A brief explanation of the items:

1. This is the hostname of the DNS server itself.
2. This is the domain name that the DNS server hosts records for. Notice that it’s underneath the “Forward Lookup Zones” section. This just means that it processes requests by name and returns IP addresses. A “Reverse Lookup Zone” processes requests by IP and returns names.
3. There are a number of DNS record types, which we’ll look at in the next section.
4. Notice all the entries marked “(same as parent folder)”. These are records that don’t have hostnames of their own. We’ll revisit this in a later section.
5. This is a dialog box for a DNS record. Notice the components.

What we see here is a DNS server that will respond to queries for records in the siron.int domain using its own database. In this regard, this is an authoritative server, because it doesn’t need to query another DNS server. If it receives a request for a domain that it is not authoritative for, such as altaro.com, it will forward that request. With Microsoft DNS, we can configure both standard forwarders and conditional forwarders. These simply tell this DNS server where to go when it is asked for a record in any domain it is not authoritative for. A standard forwarder is used for all unknown requests while a conditional forwarder is just an exception. These concepts are not really germane to this discussion, but simple enough to research on your own. If you don’t want to use forwarders, all Microsoft DNS servers are configured to use root hints by default. These are well-known DNS servers on the Internet that sit in the root domain (“.”). As you can imagine, these DNS servers are busy, so sometimes they don’t resolve as quickly.

Hopefully, the screenshot makes it obvious that DNS is really just a simple directory listing.

DNS Record Types

I’m not going to provide a detailed presentation on DNS record types as they aren’t germane to my goal with this post, but I would be remiss to not provide a few basics.

• A: The A record is the most fundamental of all DNS records. All it does is match a specific fully-qualified domain name to a specific IP address. An example of an A record can be seen in the above screenshot. Multiple A records can point to the same IP without problems.
• CNAME: The CNAME, or “Canonical Name” record points one name to another CNAME or an A record. A very common usage of this is web servers. Your actual web server might be named “IIS.domain.tld”, but you can create a CNAME that points “www” to “IIS.domain.tld”. The great benefit of CNAME records is that you can very easily point an existing name to a new one without any major infrastructure changes. You can also have multiple CNAMEs pointing to the same A or CNAME. Web host providers often do this. It allows multiple tenants to utilize the same web server without collisions.
• MX: “MX” stands for “mail exchanger”. When you instruct your e-mail client to send an e-mail to somebody@altaro.com, your e-mail client or mail server will look for an MX record in the altaro.com domain and send your e-mail to that location.
• NS: “NS” is a name server. NS records are how DNS servers in disparate domains talk to each other and are utilized by tools such as NSLOOKUP.
• AAAA: These are nothing more than A records for IPv6.

This isn’t an exhaustive list, but it gives you an idea of what goes on in a DNS server. Just as you can have multiple records pointing to the same back-end target, you can also have multiples of the same type of record with the same name that point to different back-end targets. This is typically done for redundancy, but it can also be used for a form of poor-man’s load-balancing. For example, you can have an A record for “www” that points to 192.168.10.10 and another “www” record that points to 192.168.10.11. When multiple records with the same name exist, they are provided in round-robin fashion as requests come in. The danger here is that DNS doesn’t do any validation. If one of those two hosts goes down, then every other inbound request will result in the IP address of a dead server being sent back to the client. Most clients are smart enough to try again when that happens.

How DNS Resolution Works

DNS is part of the TCP/IP suite and works way up in layer 7, if you’re still thinking about the OSI model. Its purpose is to facilitate communication way down at layer 1, and it has a long way to go to get there. The flow is pretty simple, though.

1. An application requests a connection to a resource by name, such as www.altaro.com. The system requires a matching IP address before it can process this communication.
2. The local DNS cache and the HOSTS file are checked first.  If a matching IP is found, it is returned to the requesting application. Otherwise, DNS processing continues.
3. The system checks to see if it has been configured with the addresses of any DNS servers. If not, it attempts to use other name resolution methods, such as NetBIOS broadcasting.
4. If the system does have DNS servers configured, it sends a request to one of them, asking about the resource name. Usually, this defaults to A and CNAME requests, but the DNS server can be queried for any record type.
5. The DNS server can respond in a number of ways
   1. If the DNS server is authoritative for the domain and it has a record that matches the request, it will return that record
   2. If the DNS server is authoritative for the domain and it does not have a record that matches the request, it will return a message that the record doesn’t exist
   3. If the DNS server is not authoritative for the domain and is not configured to use forwarders or root hints, it will return a message that it cannot locate the record
   4. If the DNS server is not authoritative for the domain and is configured to use forwarders or root hints, it will forward the request appropriately. This request can generally continue across a number of DNS servers, so it may take some time for an acknowledgement of any kind.
6. If the DNS server is not responding or returns an “I don’t know” response (as in 5c), the client can then choose to use an alternate DNS server, if it knows of any. If that doesn’t work, it will then fall back to broadcast.

Once the requesting application has received a valid IP, it can then perform the original communication.

That workflow is for an FQDN. What if you haven’t got one?

First, you might only have a hostname. For example, maybe your IT department has you connect to a SharePoint server by using “http://intranet”. A DNS server won’t be able to process that request correctly. By default, your connection will automatically append its own domain to any request without one. You also have the power to provide it with additional search suffixes. If it can’t get a response for a hostname request using its own domain, it will then step through each configured suffix in order, sending out a unique request for each one until it either gets a response or runs out of suffixes.

Second, you might only have a domain name, such as in the http://sourceforge.net example above. In this case, the request will be handled by a wildcard record. This is an A or CNAME record that has nothing in its name (or with some public DNS providers, an asterisk), but does have an IP or CNAME target. You saw those in the above screenshot as “(same as parent folder)”.

DNS in a Microsoft Environment

When Active Directory appeared in Windows 2000 Server, it brought with it a heavy reliance on DNS. If DNS doesn’t work, then pretty much nothing else works either. Some of this is simple convenience. DNS lookups are a lot easier to perform and understand than LDAP lookups. Storing a changeable IP in an LDAP database for quick look-up is much less efficient than DNS. LDAP’s mechanisms provide far more power than DNS, though. Active Directory is able to leverage both of these technologies to great effect – when used properly.

DNS is pretty easy to understand, and Microsoft DNS is pretty easy to use. To make a DNS server authoritative for a domain, all you really have to do is use the wizard to add that domain. It will then respond to all inbound requests for that domain and will not forward them on. Although I removed them for my screenshot, I’ve used that feature in the past as a cheap way to block access to certain things, like ad delivery sites. All you have to do is create a Forward Lookup Zone for the offending domain and create a wildcard entry that points to 127.0.0.1. Then, traffic bound for any host in that domain will break instantly. Hopefully it’s understood that this doesn’t prevent IP connectivity and could have unintended side effects. Use with caution.

Most functions of domain membership rely on DNS. When a domain member is turned on, it reaches out using DNS to contact a domain controller for authentication purposes. When a domain member needs to talk to another domain member, it starts the conversation using DNS.

Where a lot of people get themselves into trouble is by overthinking DNS. What I’ve seen a lot of is people plugging the local AD DNS entry into all their domain computers, but then plugging in an ISP’s DNS address for the alternate. “In case the AD DNS system goes down,” they say. It sounds good, except that you can’t really control which DNS server that a system might query on any given request. So, machines configured like this will have periodic timeouts and communications failures on the LAN that are difficult to reproduce. That’s because they occasionally ask an Internet DNS server for the address of a name that’s not on the Internet, and that request gets passed all over the world. Eventually, it times out and the local system is then allowed to try other methods that might work, such as broadcast. The answer is to use only your Microsoft DNS server for local machines. It can be annoying if that system goes down, but not nearly as annoying as persistent failures.

DNS and Hyper-V

There are two major places that DNS issues can cause problems in Hyper-V.

The first is for guests. I see a lot of people setting up virtual machines and plugging them into internal or private virtual switches. Their goal is to get the higher speed of the internal hardware rather than having the external switch and its pesky physical NIC getting involved. Before getting into DNS, there are a couple of expectation problems here. For one, the Hyper-V switch is already supposed to be smart enough to not send local traffic out the physical uplink. Often, this gets broken because the source and destination IPs are on different subnets, so the traffic has to hop out onto the physical network to go find a router. The other is that the internal and private switches don’t really seem to perform all that much more quickly than the network hardware. Your mileage will vary.

But, using the internal/private switches isn’t without its merits. You just have to be aware of what DNS is going to do. If you try to communicate using DNS names, it will always work exactly as described above. The source system will ask the DNS server for an IP, and the DNS server will provide one. The source system isn’t going to ask the DNS server for IPs on specific subnets or anything like that, because that’s not what DNS does. It’s just going to provide the next IP in the rotation. So, if you want to force communications on a specific virtual switch, then you need to set up a specific subnet for it. Then, you can either use manual entries in the HOSTS file(s) or you can leverage custom A and CNAME records that point to the desired destination IP. When setting this up, remember that DNS is a one-way event; the source system asks DNS for the target’s IP, but all communication after that is strictly by IP.

The other DNS issue for Hyper-V is multi-homed hosts. A lot of times, people set up dedicated management adapters, but then also choose to share the virtual switch’s adapter with the host. That results in a multi-homed system. Hosts that use multiple NICs for SMB multichannel are multi-homed. Clustered Hyper-V systems are multi-homed. The problem is that, by default, all adapters with valid IP addresses are registered in DNS. So, anything trying to communicate with a multi-homed Hyper-V host by name is going to get whichever address the DNS server provides. That address could be on an isolated subnet. The fix is simple: disable DNS registration for everything except the management adapter.

What’s Next

In the next installment in this series, I’m going to discuss ports, sockets, and their relationship to applications.