Previous:Networking Primer – Part 5.1: Network Layer – IP Addressing

We have seen in the previous section that each node in a network requires an IP address and that four part address is considerably more human readable than the underlying binary bits that it represents. Unfortunately, our meagre human brain power still has trouble with recognising and differentiating between the addresses. For the same reason, we don’t have postal addresses like this: building 1, street 52, town 34843, city 2828, region 292, country 6, we need another method of identifying the addresses of our nodes. This is done with what’s called a Fully Qualified Domain Name (FQDN). A typical FQDN looks just like the one at the top of  you browser: www.bltbytes.com. These names are very easy for us to understand, but the underlying network components can’t understand them. We need a system or method for translating IP addresses to FQDNs and vice versa. That’s where Domain Name System (DNS) joins the party.

Domain Name System (DNS)

DNS is a simple concept. It does exactly what we highlighted above. It provides a way for us to map an FQDN to an IP Address.  The use of DNS in its simplest form involves a client (requestor) and DNS server.  Let’s say that we want to use our web browser to read an article on BLTbytes. When we enter the FQDN (www.bltbytes.com) into our browser address bar and click go, the browser becomes the client in the DNS operation. It will send a query to your local DNS server to ask what the IP Address is for that FQDN. The DNS server will look this up in its database and send it back to the browser. The DNS server then steps out of the loop and the browser will initiate a direct connection to the web server that is hosted at the IP address we have been given.  Simple right?

There is however, a much more involved multi-DNS server architecture that exists behind this process. It would be great if our DNS server could hold every FQDN and IP address in the world in its database and instantly refresh, along with everyone else’s DNS servers every time there is a change, but that would be one very huge database and there would be a massive amount of synchronisation data being transmitted across the internet at any one time. It would ultimately be ridiculously inefficient and not a sensible approach. There would also be a number of difficulties around who own’s what FQDNs and who doesn’t. I’m sure that Coca Cola wouldn’t be very happy if Pepsi decided that their website should sit at www.coca-cola.com.

The naming scheme on the internet actually breaks down addresses into components that can be authoritatively controlled by those who own the addresses. Another way to refer to those components is as sub-domains or child-domains. This allows us not only to establish ownership of domain names, but also to distribute the management of those components, The data is stored and updated in a distributed manner. Behind the scenes, the naming scheme looks a little like a tree. At the top of the tree we have a root and then immediately below we have domains such as .com, .org, .net, .uk. There are actually only 13 Root DNS servers in the entire world that manage the data for where to find those top-level domains. Below those we see our organisational (or in some cases, personal) names such as “coca-cola”. Then we usually see our individual node addresses, e.g. “www” or “email”. These components make up our full address, www.coca-cola.com. When we send a DNS request to our local server, if it doesn’t own (also referred to as authoritative control) the domain name space, it will contact a root server and then be referred through an iterative process down through the branches of the tree to the DNS server that ultimately owns that name space.

Dynamic Host Configuration Protocol (DHCP)

In the early days of IP networking, all nodes on a network would be manually configured with an IP address. Addressing was not dynamic and therefore we would assign a “static” IP address to each node. Times have certainly moved on. With the explosion of devices and the requirement for mobility and flexibility (e.g. to easily attach to and detach from networks) we needed another way to assign IP addresses. This is where DHCP comes in. Using a DHCP server on our network allows us to create policies for automatically assigning and revoking IP addresses in the network. We can put controls around the types and identities of devices who have permissions to receive addresses. We can also issue a lease on each IP address so we may reclaim them after a defined period of time.

Once a device has physical (whether wired or wireless) access to the network it’s able to start the process of broadcasting requests for an address. This is a simple 4 step process that runs as follows:

Once acknowledgement is received the requesting node then starts to use the assigned address in its network stack. It’s worth noting here that the DHCP isn’t giving the node anything tangible. It’s really just saying, you can use that address. It’s possible to configure the node with an address statically regardless of what the DHCP server has done and this is where IP address conflicts may occur. An IP Address conflict is where two or more nodes on the network are advertising the same address. This sort of issue needs to be resolved quickly as it can cause havoc with communications.

While sitting on a network, a DHCP server is ultimately assuming responsibility for handing out addresses and controlling the available address pool, but DHCP does a little more than just hand out IP addresses. It also configures other information on the node, like where it can find DNS and what address it should use to get to outside networks.  DHCP can be used as an attack vector, that hackers could use to gain access to a network. If the attacker gains physical access to the network, they could install their own DHCP server and that server would automatically respond to requests, thus giving the attacker the ability to control some of the network communications.  DHCP will not only provide an IP address it also tells the requesting client where the DNS server is on the network. Can you imagine the control an attacker could have if they have control of DNS? Let’s say you wanted to upload the blueprints for your super secret new game changing widget and the DNS server is telling you that the super secret file server is at one IP address when really, it’s at another. You would have no idea that you are uploading to the wrong place until you realised it wasn’t in the right place.  This has been fixed in modern networking, DHCP servers now need to authenticate with a Domain Controller before they are able to start working on the network.  DNS & DHCP security attacks are a large area to cover and outside of the scope of this primer, but hopefully the example above gives a taste of what is possible.

The Pirate Ship: For simplicity, we’ll keep DNS and DHCP out of our analogy.

Next: Networking Primer – Part 5.3: Network Layer – IP Routing