TECH::There’s no place like 127.0.0.1. (But for everywhere else, use DNS.)

One of my favorite IT jokes is “there’s no place like 127.0.0.1.” You can get this slogan emblazoned on t-shirts, welcome mats, etc.

127.0.0.1 is, of course, localhost or the loopback address. Every device on a network has one. However, for addresses that need to be resolvable outside of the internal subsystem, we need MAC addresses, IP addresses and in most cases, routing and DNS. Think of it this way – 127.0.0.1 is your bedroom door. That doesn’t help people find your house when you invite them over, however.

Guess who’s coming to dinner?

When you have people over, you need to give them information to get them to your house. In today’s age, that’s as easy as telling someone a street number and name that they can plug into a GPS or Google maps. No more having to give step-by-step directions!

But even giving that much information can be too much, especially if that person comes over a lot (but has a terrible memory). So, in those cases, an address can be saved as a shortcut in a map app or GPS with an alias such as “Justin’s house.”

This is not unlike how MAC and IP addresses work. A MAC address is the physical pavement of the road. An IP is the street number and name. The aliased short cut? That’s the hostname.

The hostname can be served locally via a flat file, or in a database like DNS, LDAP or even NIS. Then clients and servers can query the common database for the information and use that information to find their way around the IT village.

This may all seem rudimentary to you; that’s because it is. 🙂

But you would be surprised how often DNS/hostname resolution comes up in support cases, configuration issues, etc. The reason for that is two-fold.

1) People do not fully understand DNS/hostname resolution

2) People take DNS/hostname resolution for granted

What is DNS?

To cover #1, let’s talk about DNS and what it is/does.

DNS is short for Domain Name System. It’s a centralized database that contains hostnames, IP addresses, service records, aliases, zones… all sorts of things that allow enterprise IT environments leverage it for day to day operations. By default, DNS is included in Active Directory domain deployments. It has to be – otherwise, AD would not function very well/at all. If you want to read more about that, see the following:

How DNS support for Active Directory works

Active Directory-Integrated DNS

Configure a DNS server for use with Active Directory

However, DNS isn’t just used for Active Directory and isn’t isolated to only Windows environments. DNS has been around for a long time and is critical in numerous widely used IT services, including:

• NAS (NFS and SMB)
• Kerberos
• Microsoft Exchange
• LDAP
• Various other 3rd party applications

The above list is by no means complete, but gives a general idea of how integral DNS is to day to day IT shops.

What is so difficult about DNS?

DNS is not extremely complicated. However, there are general high-level concepts that get mistaken from time to time.

Servers

DNS servers themselves are concepts that can get lost on people. These contain the records, zones, etc. They also may replicate across the network to other DNS servers. They require specific functionality, such as being able to listen for DNS requests on port 53, caching requests, acting as authoritative servers (SOA) for DNS updates, etc.

Records

This is one thing that trips a lot of people up, mainly because there are many different types of records. Some of the main/common ones include:

• A/AAAA records (for IPv4/IPv6 addresses)
• CNAMEs (aliases)
• MX (mail exchange)
• NS (name server)
• PTR records (pointer/reverse lookup)
• SOA (start of authoritative zone)
• SRV (service records such as LDAP, Kerberos KDC, etc)

Zones

Zones are used to direct requests from clients to their appropriate locations and/or forward them to other name servers. For example, dns.windows.com might be the name of the Active Directory domain, but you might also have DNS zones in other locations that exist on other name servers. If so, you could add a zone (such as bind.linux.com) and add NS records to forward requests on to the appropriate name servers running BIND. This allows for improved performance of lookups, as well as scalable DNS environments.

NetApp’s clustered Data ONTAP actually allows storage admins to configure individual data LIFs as name servers to act as DNS zones in a Storage Virtual Machine. This comes in handy for intelligent DNS load balancing in clusters and is covered in TR-4073: Secure Unified Authentication on page 27.

Wither DNS?

There is plenty more to DNS than the above. However, if you already know and understand DNS, you can see why it’s easy to overlook it and take it for granted. When configured properly, it just works. It’s not fancy. It’s generally robust and resilient. And with DDNS, you don’t even have to go in and add records to existing DNS servers. Clients do it for you. So when a problem *does* occur, it becomes a “forest for the trees” problem where DNS is one of the last places many admins look. This is a mistake – DNS should be one of the first things checked off the list as “not a problem” when troubleshooting, as it’s so important to so many things in IT.

Best Practices

Most DNS servers out there have documented best practices, and any best practice for a DNS server should come from a vendor. However, there are universal best practices that are pretty much no-brainers when it comes to managing DNS.

• Use multiple DNS servers: This provides redundancy, eliminates single points of failures, allows load balancing, etc.
• If using multiple DNS servers, ensure they are all in sync: Replicate all the zones and records on a regular interval. Check error logs to ensure that replication is occurring normally and without error.
• Be thorough in hostname record creation: Don’t just add a forward lookup record. Add the PTR, too. And don’t create a CNAME unless you have an A/AAAA and PTR record to point it to.
• Make sure your clients are configured to use the correct DNS servers and zones
• Avoid using local hosts files if possible: Everyone forgets to update those things. And imagine having to update 1000s of files every time an IP address or hostname changes….
• Ensure proper service records (SRV) are in place for services.
• Review the vendor recommendation for enabling recursion. Some vendors want it disabled.
• Know your DNS port number (53) by heart. This will save you troubleshooting headaches.
• Learn to love packet traces for troubleshooting, as well as ping, nslookup and dig. Just be careful with ping. General rule of thumb is, if you can ping the IP but not the hostname, check DNS.

There are tons of other best practices out there, including this Cisco doc, this Microsoft doc and this Wikia article. For Name Services Best Practices related to NetApp’s clustered Data ONTAP, see the new TR I wrote on the subject (TR-4379).