Names are important. I get steamed when people continue to mispronounce my last name or when someone corrects my pronunciation of the town I live in. But, where names are really important are in networks. One of the most common issues I face regularly in networking is name resolution.
Why is this important? Let me start at the beginning. Most users take for granted when they fire up their computer and connect to a network that they will be able to go out on the internet and get to Facebook (I still think it is a fad). But, for that to happen, there are several things that have to happen in the background for that to work.
On a TCP/IP network, every computer or device must have a unique address (IP). These can be statically set - causing some administrative overhead of tracking what addresses are free (you have to have an IP before you can search for a free address). The easier solution is to dynamically assign addresses - this requires a machine on the network usually using the Dynamic Host Configuration Protocol (DHCP) to give out the addresses (and other settings I'll get to latter) and track who has what address. Thus, preventing the dreaded IP conflict (two machines having the same IP address), which happens more often than not on statically assigned networks.
The tracking is done based on the MAC address of the network interface. This SHOULD be a unique string of twelve hexadecimal numbers. The first six identify the manufacture of the network interface and the last six identify the unique device. Ask me what happens when you change the MAC addresses of several network interfaces on the same network to the same string. You could do that back in the day... But that is a topic for another day.
The DHCP server gives out more than IP addresses. At a minimum, the host is given an IP address, a Subnet mask, a Gateway address, and a DNS server. The Subnet mask helps the host to determine what other hosts are on the same network (i.e. have the same range of IP addresses). And the Gateway address is where the host should send data that is intended for another network (i.e. outside the range of IP address used on their network). There are many more things that DHCP gave give out. Such as Time Server, Network Name, and even what IRC servers are on the network. But for this discussion I will focus on IP, Subnet Mask, Router/Gateway and DNS Server.
The DNS server (Domain Name Service) is where the name resolution magic happens. Computers communicate with numbers - even what we see as text are actually numbers to the computer. www.mckeand.biz is much easier to remember than 24.314.19.168 for us humans. So DNS translates the www.mckeand.biz to an IP address. There are other records in DNS that can give information about a domain (such as mckeand.biz), but again that is off topic.
So, What is the topic? Name resolution always bites me in the back side. I have spent more hours that I want to admit chasing issues on a network that turned out to be name resolution. The issue popped up yesterday at what should of been an hour or two at my church updating the network. I replaced three 10/100 switches with new Ubiquiti Unifi managed gigabit switches. That went well enough, I was able to integrate them into the Unifi Console (I already manage the four wireless AP on the site) without an issue. The Unifi Security Gateway (USG) on the other hand fight me tooth and nail. I could not get it to integrate to save my life. The process is called Adoption in Ubiquiti's vernacular. It is a simple process, I've done it many times at many locations.
- I connect the device I want to adopt to the network.
- Find the IP address assigned via DHCP.
- Use Secure Shell (SSH) to connect to the device.
- Issue a set-inform command: set-inform http://unifi.mckeand.biz:8080/inform
- Go to the Unifi controller and adopt the device
- Issue the set-inform command again.
The device would show up in the console and manage the device.
But, the USG would not adopt. Not until I entered the IP address of my controller. This should of told me something was up. The USG has two interfaces (actually three, but one is disabled). Each interface should have an unique set of IP settings. The LAN interface is statically assigned - most servers and network equipment should be static. The WAN interface in this case is dynamic - uses DHCP. The ATT uVerse modem/router thing insists on all dynamic, in general this should not be an issue. There is a mechanism to have the public IP of the modem assigned to a device on the LAN (DMZ+ is what they call it). Fine, I had the modem give the public address to the USG via DHCP. The modem also gives out its own address as DNS. Normally, this would not be a problem, but the modem's LAN side is in the 192.168.1.x range as is the LAN side of the USG. So the USG is told use 192.168.1.254 as a DNS. When the USG tries to look up unifi.mckeand.biz by talking to 192.168.1.254 which it assumes is somewhere on the LAN interface, it fails. This is why I was able to adopt the USG using the IP address of the Unifi controller.
This continued to be an issue because I could not get the firmware of the USG to update. I dug around and found how to override the DNS supplied by the uVerse modem. I then was able to force the firmware update via SSH. I think I am done breaking things at the church.
