Special: Datacenters, DNS, and TCP Handshakes

January 24, 2021

After working at Amazon for a few weeks now, I have something that I want to discuss that I found to be a major difference between an on-premise datacenter and a cloud-based datacenter like AWS or Azure. One of the key differentiators is how you interface with your remote resources. In the bad old days you could simply attach to things directly, because you were likely on the same network where your resources existed. If you wanted to work with identities you could pull up your Active Directory Users and Computers console and make your changes. It’s different if you’re working with a software defined datacenter, where you have to administer these resources through a web page for the most part. Now, you may be thinking: DJ, both Azure and AWS have command line interfaces. I am typing in these commands directly into the console to administer these services. Well, I have a bit of news for you, even these consoles take what you’re typing into them and translate that into the language of the web.

But, what is this mysterious language of the web I keep mentioning? The language of the web is HTTP. If you want to interact with these datacenter as a service solutions, you have to play by their rules. That means using HTTP methods such as GET, POST, PUT, and DELETE. 

But, before we dive off into that wild world, I feel like we could all benefit from establishing a baseline understanding around all this, and that requires how we find those resources, connect to them, and finally see what happens when things go wrong. Since the different HTTP methods mean different things to different services (even within one cloud service) we won’t go into methods, but we are going to talk about HTTP Status Codes. This is a lot to cover. That means we’re going to spread this across two episodes.

Today we’re going to deal with the discovery and connectivity side of the equation. This includes some old favorites like DNS and TCP. Next week we will get into the real topic: HTTP status codes. But, let’s dive right in with DNS. 

Put yourself in the place of your everyday browser. You can choose Firefox, Chrome, any other browser that is Chromium-based, or even Safari. If you choose Safari for this, we won’t judge. Unless it’s on Windows. If it’s on Windows, we’ll have questions. Lots of questions. You should, too.

But, now that you’re a browser–yes, that still includes Safari–think about how you would go about communicating with a web server. Let’s look at accessing our shows site at a high level, assuming the URL is www.backfromthefutureshow.com.

  1. You check to see if the domain name to lookup is in your local resolver cache or HOSTS file. In this case, it’s not.
  2. You send out a DNS query to find the IP address of your domain name. This request is handled by your friendly neighborhood Recursive Resolver. But, it also doesn’t know the IP address you need! So, the Resolver has to ask a Root Server.
  3. The Recursive Resolver talks to a Root Server on your behalf, asking for the IP address of a DNS server that is authoritative for “.com” domains. (Now, let’s pause here. You may be thinking that the DNS server is starting from the wrong end. But, it’s not. Domain names are actually resolved backwards.) So, this new “.com” server’s IP address is returned to the Recursive Resolver. 
  4. The Recursive Resolver then talks to the “.com” DNS server and asks for the same full address. Sadly, the “.com” server doesn’t know the right IP address, either, but it does know a name server that is authoritative for “.backfromthefutureshow”. So, it sends the Recursive Resolver that IP address. 
  5. The Recursive Resolver asks the name server authoritative for “backfromthefutureshow.com” for the IP address of “www.backfromthefutureshow.com” and this time it knows it! Amazingly, it sends the Recursive Resolver the address of “103.115.16.125”. 
  6. Now that the Recursive Resolver has a final destination IP address, it forwards that back over to you. 

Do you think it’s complicated? Well, it is. But, it gets the job done. While we’re on the topic we can’t fail to mention that it’s not very privacy savvy, but we can talk about that on another show.

Here’s something fun you can try at home. Bring up a Command Prompt in Windows and type in…

> nslookup www.backfromthefutureshow.com

The output it returns will tell you the DNS server you’re talking to and it’s IP address. It will then give you name of the server you’re looking for, its IP address, and sometimes the alias if it’s available. It’s a great tool at helping you troubleshoot DNS issues. Especially if the initial server is not what you were expecting. 

Now, it’s time to connect to our web server. This is the simple part, given we are not going all the way down to the packet and frame level to discuss it. Just remember, you’re a browser. Even you, Safari. 

  1. You open a TCP connection by sending the web server IP a packet with a SYN flag set.
  2. The web server sends back a packet with the SYN and ACK flags set. 
  3. You then send the web server a packet with the ACK flag set. 

This process is called the TCP handshake and now your TCP connection is open. 

That sets us up to start sending our HTTP packets. But, that will have to wait for next week. We’re going to leave this one on a cliff hanger for now. I hope you all understood this rough explanation. If you had any issues following along or any questions about what we heard today, feel free to join our Discord. We’re there to talk about the show, but also about how to get ahead in your career, earn advanced certifications, or even enter the I.T. field. Anyone can join. You can be a DBA, Network Engineer, season Helpdesk Technician, or even a Safari user. We don’t judge. 

Comments are closed.