Why the use of DNS “short names” should not be used as a strategy

simple DNs setup wThe purpose of this post is to discuss why short names are not a good strategy.

First lets define a few terms.

DNS – Domain Name System, simply put, an application that translates computer names into ip addresses.
IP address – Internet Protocol address – basically the numerical designation of a computer. Think of it like a telephone number.
domain – a grouping of host records. All hosts in the domain have the domain name as their suffix.
host name – the name of a computer or service.
Fully qualified Domain name (FQDN) – this is the term that is used to refer to a name of a computer or service that has the host and the domain name. For example hostA.domainX.com. The first part is the host name and the second part is the domain name.
Short names – the term used to refer to a name that does not have the domain name written out after the host name. So when you type “hostA” you have typed a short name.
Suffix list – a list of domain names. This is usually written domainX.com domainY.com domainZ.com.
There can be multiple entries but it is not, in my opinion, a good practice to have more than two.
DNS server – a computer that runs a service that will translate a name to an ip address. Think of it like a phone book. You have a name, and you need to look up the corresponding telephone number. On the internet IP addresses are the telephone numbers of computers.
DNS server list – a list of DNS servers. This is the list of servers that the client computer will make request of (query)  to find the IP addresses of the names.
nslookup – a command found on nearly all computers that will attempt to look up the IP address of a host name.

Now  lets see how they work.

When you want to look up a name to find it’s IP address you can type the following command and it will attempt to look up the name. The behind the scenes process that is being used is also used by browsers and all other applications.

Example:

nslookup hostA

What happens is that each entry in the suffix list, if you have one configured, is appended in turn to the short name, hostA, to form a Fully qualified Domain Name (FQDN) and a request is made to the DNS server with this FQDN and the server attempts to look up the name. If the server cannot find the name the nslookup command appends the next item in the suffix list to the short name and tries that FQDN. It keeps doing this until it runs out of items in the suffix list or reaches a timeout value.

Lesson 1: There is no such thing as a short name. The suffix list is always appended and the DNS servers will only look up an FQDN.

What some organizations will do is create two different DNS servers. One serves up the information for domainX.com and the other DNS server will serve up the names for domainY.com.

But the host names in both DNS servers will be the same only domainX.com will have different IP addresses for each host name then what domainY.com will have.

The advantage to this is that if you lose one data center, domainX.com you just have to change your suffix list and your DNS servers list to point to domainY.com and you are back up and working.

It sounds pretty slick, but this leads to lesson 2.

Lesson 2: Just because you can do a thing, does not mean you should do that thing.

The problems with the short name strategy:

You have to push the suffix list and the DNS servers list to every client, workstation and server in the organization. There are ways to do this, but remember, you are in the middle of a disaster so most things will not be working. So relying on changing every client in the organization to change in the middle of a disaster is not a reasonable expectation.

You could have a dedicated Disaster Recovery (DR) site that is already configured to point to domainY.com. This strategy has it’s own problems with testing, synchronization, data on the old domainX.com, workstations that now cant be used unless they are reconfigured. It increases the amount of logistics and resources needed to support an organization in the event of a disaster.

Lets say you still go forward with the strategy. You have devised a way to push out configurations to workstations and servers. Now you are saying that this push will never happen in whole or in part until it is needed. In other words you are saying that people and processes are perfect. Again, that is an unreasonable expectation since people by definition are imperfect. Whole or in part means that the organization wide push will not occur by accident (the whole part) and that no individual will have their particular workstation or server changed by themselves or by an administrator (the “part” part). And in the end that’s just a matter of hoping. Well engineered infrastructures by definition are well defined. Well defined means that something works the same way all the time no matter what the circumstances. The use of short names completely dismisses the concept of “well defined”. Your basically saying, “sometimes it’s one way, sometimes it’s another. It depends on the situation.” Hence you do not have a well engineered infrastructure.

You also have to be mindful of new technologies that may try to find a DNS server whether one is configured or not and try to use the first one it finds which may be the wrong one. The last thing you want is production data going to a DR or development site or what may be worse, development data going to a production site. A well defined DNS policy that enforces the use of FQDN would alleviate these types of fears.

It is not just the suffix list that you have to worry about. What if the applications in domainX.com store URLs in an FQDN format (as they should). When you switch to domainY.com and assuming that the database is replicated in domainY.com the URLs will be dead because domainX.com is dead.

You also have to worry about application specific configurations that store the list of servers. These can be set up as short names, if the application allows it, but you still have to worry that the applications are pointing to the correct DNS servers or that they find the correct DNS servers. That is a tough thing to guarantee all the time. And remember, An application only has to be miss-configured once to cause a business outage.

If the business buys another business that relies on short names and both business have hostA in their respective domains (lets say domainX.com buys domainZ.com) then adding domainZ.com to the suffix list will cause one of those applications at hostA to fail. This means that all the supporting infrastructure and clients that use hostA need to be re-mediated to use the FQDN to get the business back up and working.

Lets say you don’t want to change the DNS server list on every client and server in the organization so you configure every client and server in the organization with DNS-server-1 and DNS-server-2. Now all you have to do is change the suffix list to point the surviving workstations and servers to the DR site. This is fine, but now you walk an even finer line to disaster since the only barrier you rely on is a properly configured suffix list, application configuration and database entry on every device in the organization. This does not even consider the problem of local caching of DNS entries.

Lets say you want to unify your DNS/DHCP to obtain a holistic IP management (IPAM) view. Within that integrated IPAM you have to somehow accommodate the short name infrastructure. In other words your Enterprise wide standards will be compromised to accommodate a flawed fail-over strategy. You don’t want your Enterprise standards to enable flawed strategies. You might as well not have an enterprise standard at that point. But enterprise standards contribute to making the business competitive and so to not implement an enterprise strategy or to implement a flawed enterprise strategy is not an option.

Lesson 3: Don’t code using short names. Don’t use short names as a strategy. Don’t rely on short names. Don’t encourage the use of short names.

Inherently the use of short names as a fail-over strategy implies that DNS is a barrier of some kind. Nothing could be farther from the truth. DNS is not a barrier. Firewalls and to a lesser extent routing are barriers. DNS resolves names and it should resolve all names through out the enterprise. Yes their is a distinction between an external DNS and an internal DNS. But these are separated by a firewall and they are designed from the beginning to be distinct. Notwithstanding the concept of a split zone the external and internal DNS servers and the domains that reside on them are all distinct and they are treated that way both in form and function. If you don’t have a split zone then the external and internal DNS areas would force you not to use short names or duplicate names. You would not want to type in www in hopes of getting to www.external.domain.com only to find yourself at www.internal.domain.com because internal.domain.com is in your suffix list.

Lesson 4: Do not use duplicate host names if you can help it or only use duplicate host names if you have an FQDN policy. Even if you have a strict FQDN policy heavily discourage the use of duplicate host names.

The use of short names and the suffix list was devised as a way to make typing URLs easier. And they can still be used in that sense. Just apply lesson 3 and don’t rely on them as a disaster recovery strategy.

Also, a long suffix list will eat up bandwidth as each item in the list will be tried until a match or a negative answer is found. Using the FQDN will go a long way towards easing the band width usage and keeping the suffix list small will go even farther. In this sense the use of short names is a tactic and not an enterprise wide strategy. You don’t rely on this behavior in applications and in infrastructure development.

Lesson 5: keep the suffix list short. Two to three entries should be all you need.

But this rule depends on your infrastructure. Usually multiple entries in your suffix list point to deeper problems in the infrastructure.

Summary:

Lesson 1: There is no such thing as a short name. The suffix list is always appended and the DNS servers will only look up an FQDN.
Lesson 2: Just because you can do a thing, does not mean you should do that thing.
Lesson 3: don’t code using short names. Don’t use short names as a strategy. Don’t rely on short names. Don’t encourage the use of short names.
Lesson 4: Do not use duplicate names if you can help it or only use duplicate names if you have an FQDN policy. Even if you have a strict FQDN policy heavily discourage the use of duplicate host names.
Lesson 5: keep the suffix list short. Two to three entries should be all you need.

If you can think of any other reasons why short names should not be “relied” upon as a strategy I would like to hear your comments.

 


Comments

Why the use of DNS “short names” should not be used as a strategy — 1 Comment

  1. Lesson 6: When using nslookup in an automated fashion to get IP addresses for a large number of DNS Names, remember that the output from nslookup contains the fully qualified DNS Name. So, when you scrape the results of the nslookup command, you will not be able to match hostA from your original list back to hostA.domain.com from the output of nslookup.

Leave a Reply