This is week 10 of the Google Professional IT Certification course on coursera.org.
. . .
Intro to Network Services
This week, we’re in to some more parts of computer networking. Skimming the video titles here, I think I know what most of these topics are – DNS, VPNs, DHCP—I have read about NAT but I’m not sure I can explain it… So, there may look like there are a lot of sections here, and several quizzes, but I don’t think it is going to be as bad as Week 8 and the binary computation of subnetting. Here we go…
Network services are the components of computer networking that answer requests for data from clients. There are far more network services than can be covered in this course, or probably ten courses, so we’re just going through this at the overview level, and will only be discussing network services that relate directly to networking.
That’s because, as an IT support person, it will be important to know where to look when networks stop functioning.
Why Do We Need DNS?
Computers only understand two things, 1 and 0. They are programmed to interface with people in more understandable terms—language, pictures—but a computer really only understands binary, and this is not an easy language for humans to work with. This is where DNS comes in…
An IP address is a 32-bit binary number. We tend to write them out as 4-octet decimal numbers, like 192.168.0.10, which is easier to remember than the binary equivalent (I looked this up): 11000000.10101000.00000000.00001010. While a 4-octet decimal number is easier to remember than a string of 1s and 0s, it is not easy to do for every website you ever want to visit regularly, so there is something that translates IP addresses into words: Domain Name System, or DNS.
“[DNS is] a global and highly distributed network service that resolves strings of letters into IP addresses for you.”
Instead of having to remember that the website where we like to check the weather is 184.108.40.206, we can just remember to go to “weather.com.” That’s called the domain name, which is what we call something that can be resolved by DNS.
This means that when a website with a certain domain name and IP address changes web hosting companies, thereby getting a new IP address, they can use DNS to changes what IP address their domain resolves to, so that users can still just type in for the old domain, even though the website has migrated to a completely different IP address.
DNS allows big administrative changes to happen without needing users to learn new information.
In order to maintain network efficiency, DNS helps route traffic based on regional domain resolution—like if there are duplicate servers for a website, one in Japan and one in Canada, the client in New York will be routed to the server in Canada and the client in Osaka will be routed to the server in Japan.
DNS is a very powerful and important network service. This is an understatement.
The Many Steps of Name Resolution
DNS simply takes the names humans like to use for websites and resolves them to the numbers that computers understand. The process of turning a domain name into an IP address is called Name Resolution. This is how that process works. Remember that a DNS server needs to be configured at a node on a network. There are always four particular things that must be configured on a device to function on a modern network:
- IP address
- Subnet mask
- Gateway for a host
- DNS server
While you don’t technically need a DNS server configured, you are going to find it very difficult to operate a computer that is setup that way.
There are 5 primary kinds of DNS servers, and any DNS server can be fulfilling multiple of these roles at once:
- Caching name servers
- Recursive name servers
- Root name servers
- TLD name servers
- Authoritative name servers
Caching and recursive name servers are usually maintained by ISPs. A caching name server keeps a record so that and they serve to “store known domain name lookups for a certain amount of time.” This prevents having to “lookup” again every time a TCP connection is requested. Most caching name servers are also recursive name servers, which “perform full DNS resolution requests.”
Say you have two computers on one network, both configured with the same DNS server. The first time the first computer requests “https://wrongtree.info” the name server performs a “fully recursive name resolution” and finds the correct IP address. That IP address is delivered to the first computer, then also stored—cached—in the DNS server so that when the second computer requests “https://wrongtree.info” the DNS server does not have to look it up again, it just sends the IP to the requesting computer.
Every domain name that is cached has a TTL (time to live) that is configured by the domain owner, and specifies how long a name server is allowed to cache an entry before it is required to perform another full resolution. TTL used to be set at longer intervals, but because bandwidth constraints have eased over the years they are getting shorter and shorter. A long TTL can slow down changes from becoming known to the entire internet.
When a fully recursive resolution is requested, the recursive name server contacts one of the world’s 13 root servers, and they are responsible for directing requests to the correct TLD server. A technique called anycast is used to route this traffic around the globe based on location, congestion, and link health, and means that there are no longer actually 13 root servers. There are really more like 13 authorities that perform root name lookups. Not sure why you couldn’t just say that from the beginning, video guy,,,)
The root server sends the name server the address of the TLD (top-level domain) server that should be queried. The “top-level” means the “dot whatever” part of the web address. Every TLD has a network of name servers “working for” it.
So, once the TLD name server is consulted it sends back the address for the authoritative name server that should be contacted to resolve that original address.
This hierarchy is responsible for the stability of the internet. It prevents malicious parties from re-directing traffic.
This system also helps speed up the internet by allowing name resolutions to be stored so that every time a computer requests to make a TCP connection a full resolution does not need to take place.
DNS and UDP
DNS is one example of an application layer service that employs UDP in the transport layer instead of TCP. Remember that UDP is connectionless, meaning there is no initiation (the handshake, etc.) or teardown of a connection so there is less traffic overall.
A single DNS request can “usually” fit within one UDP datagram, making it an appropriate use of UDP. Note that DNS itself creates a lot of traffic, even when caching name servers are used. If TCP was used, the host making the request would have to send a SYN packet to a local name server on port 53, which would then have to respond with a SYN/ACK, and then the originating host would have to respond with an ACK packet just to connect to the local name server, then send the actual DNS request, which would require an ACK response from the name server. That’s 5 packets just to send the DNS request. If the IP address isn’t cached on that local name server, the full DNS resolution needs to be performed. The local name server would have to handshake with a root name server (16 packets) then close that connection, then 11 more packets to get the info from the TLD server, then 11 more to get the actual IP from the authoritative name server. That’s 44 packets after all the connections are closed just to resolve an IP address using DNS performed over TCP. That is a lot of traffic just to be able to start sending and receiving traffic with the actual intended connection.
Using UDP, the originating host sends one packet to the caching/recursive name server requesting a DNS lookup. That server sends one UDP packet to the root server, which sends a response with the TLD nameserver. The recursive server sends one packet to the TLD server, which sends one packet in response containing the authoritative name server. The recursive name server sends a request to the authoritative name server, which responds with the IP address for the requested domain. The local name server then sends that response to the original host. That’s a total of 8 packets.
That’s why UDP is an important protocol, especially for services like DNS. Since UDP doesn’t have any error resolution, if there is an error or no response during a DNS lookup, the host will just make the request again. A DNS server never does anything but respond to incoming lookups.
DNS over TCP does exist and is in use. When a response for a request is too large for a UDP datagram, the nameserver will respond with an “explanation” that the response is too large and have the host begin to open a TCP connection.
Sergio IT Great Field
Yes, that is the name of this video. Sergio is network engineer. He work with many stuff. He teach him own stuff. He thinks that you don’t need a 4-year degree to work in IT, you just have to be able to learn new things. Keep learning. Got it.
“Have you ever bought a domain name for a personal website? If so, share your experiences with your classmates. If you’ve never done this before, ask questions and learn from your classmates to explore more.”
I have and you are reading it. Wow.
Name Resolution in Practice
Resource Record Types
I am reminded once more that DNS is one of the most important technologies to understand when troubleshooting network problems.
DNS works with a set of “defined resource record types.” These allow for different kinds of DNS resolutions. There are dozens of these, but we are going to cover the most common.
- A Record: used to direct a domain name at a certain IPv4 IP address. At its most simple, a single A record is used for a single domain name, but a single domain name can have many A records. This allows for a DNS Round Robin, which is a technique used to balance traffic across multiple IPs. “Round robin is a concept that involves iterating over a list of items one by one in an orderly fashion.” For example, because we get so much traffic, we have configured four A records at the authoritative name server for the wrongtree.info domain. Let’s say these are
So when the “first” lookup is requested all four are returned to the resolving host, but it would know to use them in the order they are returned, and would first try to connect to 10.1.1.1. IF that connection failed then it would try 10.1.1.2.
The “second” host requesting a lookup would receive the same 4 IP addresses, but 10.1.1.1 would have been moved to the bottom of the list, and it would first try to connect to 10.1.1.2.
This cycle will continue for all lookup requests, which effectively balances traffic across all 4 IPs.
- AAAA – “Quad A” record: A quad-A record is very similar to an A record, except that it returns an IPv6 address.
- CNAME Record: This redirects traffic from one domain to another. This is very common, and can be used to redirect requests for, say “blurgg.org” to “www.blurgg.org.” The “C” in “CNAME” means CNAME records are useful because you only have to change the canonical name in one place, instead of creating two identical A records, one for “blurgg.org” and one for “www.blurgg.org.” If we use these two A records, and someday decide to change the domain name, we’ll have to change both A records. Using one CNAME pointing “blurgg.org” to “www.blurgg.org” you will only ever have to change that one CNAME if the domain changes.
- MX Record: This is the Mail-Exchange record used to deliver email to the correct server. Because mail servers are usually separate machines from other web servers or other servers, the MX record is a way to make sure that email traffic is directed to the mail server.
- SRV Record: The service record is used to define the locations of particular services, just like the MX record, except that it can be configured to return info on many different services.
- TXT Record: The Text record was originally intended to leave human-readable notes about domains and networks. As the internet has evolved the TXT record has been used to hold data for other computers consumption. The TXT record can be used to give configuration information to an email service provider, for example.
Anatomy of a Domain Name
Any domain name has three primary parts. Let’s use our famous overlords as an example.
The three parts are separated by a period. “com” is the last part, and is known as the top level domain, or TLD. There are a specific and restricted set of TLDs, but there are more and more to create more space. TLDs are defined by the Internet Corporation for Assigned Names and Numbers, or ICANN.
The second part of a domain name, in this case “google” is called the domain. A domain is used “to demarcate where control moves from a TLD name server to an authoritative name server.” Domains can be created and chosen by anyone, but they must be followed by one of the registered TLDs.
In this case the “www” is what is known as the subdomain. (It can also be referred to as the hostname as long as it has only been assigned to one host.)
Combining all three parts subdomain.domain.top level domain gives you what is called a Fully Qualified Domain Name (FQDN).
(I would like to point out here how the video chooses to define FQDN: “When you combine all of these parts together, you have what’s known as this”. This quality of writing getting paid for by me?
Subdomains can be chosen by anyone who controls a domain, which can be purchased from and registered with a domain registrar—a company licensed by ICANN to sell unused domain names. You rarely see too many subdomains in use, but DNS can (“technically”) support up to 127 “levels of domain” for a single FQDN.
Each section of a FQDN is limited to 63 characters, and a FQDN can only be composed of a total of 255 characters.
An authoritative name server is responsible for resolution requests for specific domains, but they also do more than that. An authoritative name server is responsible for a specific DNS zone, which is a hierarchical concept. Root name servers are responsible for the root zone, and TLD name servers are responsible for the zone covering its specific TLD.
DNS zones allow for better control over multiple levels of a domain. As more resources are added to a domain, network admins can divide the domain into zones. Instead of company.com with three locations in one DNS zone, you can divide it up such as boston.company.com, cairo.company.com, and osaka.company.com.
If there are 200 desktops at each location that means there are about 600 A records to keep track of for the single zone of company.com. but by dividing into DNS zones (based on the location and subdomain of each office). This requires 4 authoritative names servers, one for company.com and one for each location.
Zones are created using zone files, which are simple records that declare configurations and resources for a particular zone. A zone file must contain a Start of Authority, or SOA resource record declaration. This “declares the zone and the name of the name server that is authoritative for it.”
Along with an SOA there is also often an NS record, which indicate other name servers that may be responsible for the zone.
You may also find some of the other resource record types that we have discussed, including A, AAAA and CNAME records. There may also be configurations like default TTL values for records served by the zone.
You may also encounter something called a Reverse lookup zone file which allow “DNS resolvers ask for an IP and get the FQDN associated with it returned.” These files are like zone files but instead of A or AAAA records there are Pointer resource records (PTR) which resolve an IP to a name.
Dynamic Host Configuration Protocol
Overview of DHCP
DHCP helps manage modern networks. Every device on a modern TCP/IP network needs to have four things properly configured:
- IP Address
- Subnet mask
- Name Server
On most networks, three of these are often the same, but we know that IP addresses must be unique. Dynamic Host Configuration Protocol takes a lot of the work out of assigning IP addresses.
DHCP is “an application layer protocol that automates the configuration process of hosts on a network.” DHCP allows a device to contacts a DHCP server when it connects to the network and will be given all the configuration information.
For devices like routers and servers on a network it is usually important that they have static and known IP addresses. Without a static IP address on, say, a DNS server it would be very difficult to connect to it if there was a problem. But for many client devices it doesn’t matter what IP they have, just that it is on the correct network.
By using DHCP you can set aside a range of IP addresses for client devices.
There are a few ways DHCP can hand out IP addresses. The most common is dynamic allocation: “a range of IP addresses is set aside for client devices and one of these IPs is issued to these devices when they request one.”
Automatic allocation: “A range of IP addresses is set aside for assignment purposes.” The only difference between automatic allocation and dynamic allocation, except that with automatic allocation the DHCP server keeps track of which IP addresses are assigned to which devices, and then will assign the same IP to a device in the future if it is available.
Fixed Allocation: “Requires a manually specified list of MAC address[es] and their corresponding IPs.” When a device requests an IP address the DHCP server looks up the device’s MAC address for its corresponding IP address. If there is no entry for that MAC address it may fall back on an automatic allocation or it may refuse to assign an IP altogether. This can be used as a security measure, because it allows you to only allow known devices onto the network.
DHCP can also be used to configure other things, such as network time protocol (NTP) which is used to synchronize all the devices on a network.
DHCP in Action
As an application layer protocol, DHCP relies on the network, data link, and physical layers, but it is actually used to configure the network layer. How does that work?
DHCP discovery is the process used when a DHCP-configured client requests network configuration information. This process has four steps:
First, the DHCP client sends out a DHCP discover message, “DHCPDISCOVER” which is a special broadcast message because it doesn’t have an IP address. DHCP listens on UDP port 67 and these broadcast messages are always sent from UDP port 68. The message is encapsulated in a UDP datagram with a source port of 68 and a destination port 67. This is encapsulated in an IP datagram with a destination IP address 255.255.255.255 and a source 0.0.0.0. Because this is a broadcast it is delivered to every node on the network, and if one of those is a DHCP server (listening on port 67) it will receive this broadcast message.
The DHCP server then consults its own configuration and determines which (if any) IP address to assign to the requesting client. This depends on what kind of allocation system the DHCP server is using.
When the server has identified an IP to assign, it returns a DHCPOFFER message, with a destination UDP port 68, a source port 67, a broadcast IP of 255.255.255.255 and the server’s actual IP as the source. The DHCPOFFER message contains the MAC address of the machine that sent the original DHCPDISCOVER message, meaning that even though this is a broadcast message only the correct client will accept this IP address.
There are networks that may have more than one DHCP server running at a time, and clients can be configured to only accept IP addresses from a certain range or DHCP server. In most cases, though, at this point the client would respond to the server with a DHCPREQUEST message, telling the server that it would like to be assigned the IP address in the DHCPOFFER. The server then sends an acknowledgement message, or DHCPACK (as a broadcast) and the network stack on the client can use the configuration information from the DHCP server to set up its own network layer.
After this, the client should have all the information it needs to fully operate on the network. All of this information is called the DHCP lease, because it includes an expiration. Depending on the network, the lease could last hours or days, and after the expiration the entire process has to be repeated. If the client disconnects from the network it releases its IP address, which the DHCP server can then put back in the pool of available IP addresses.
Network Address Translation
Basics of NAT
Unlike other recent discussions about protocols, Network Address Translation (NAT) is a technique instead of a defined standard. Different operating systems and hardware manufacturers have implemented NAT in different ways, but what it accomplishes is largely constant.
NAT is pretty much what it sounds like—taking one address and changing it into another. This can be employed as a security measure or to help preserve the limited amount of IPv4 address space. More on that later.
NAT is “a technology that allows a gateway, usually a router or firewall, to rewrite the source IP of an outgoing IP datagram while retaining the original IP in order to rewrite it into the response.”
A simple example is two networks, A and B, with a computer in each network and a router between them configured to perform NAT. When Computer A on Network A sends an IP datagram to computer B on Network B, the router will replace the source IP with its own IP, so that Computer B will see the source as the router, not Computer A. When computer B responds, the router knows that the destination is actually Computer A. This means that Computer B does not know the identity of Computer A, which is known as IP masquerading.
No one can connect to your computer if they don’t know what IP address you have.
When you have many computers in a network space all passing traffic through a device performing NAT, this is known as One-to-many NAT.
NAT and the Transport Layer
There are several more techniques used for NAT in the transport layer. When a router is performing one-to-many NAT it is replacing all the source IP addresses with its own before sending traffic out to the internet or another LAN. So when all those responses come back they all have the same destination IP address—that of the router. In order to allow NAT to work for incoming traffic, there is a technique used called port preservation.
Port preservation means “the source port chosen by a client is the same port used by the router.” Remember that outgoing connections will use a port from the ephemeral ports of 49,152 through 65,535. Basically, the router remembers which port was used for a connection and keeps that port open so that it can forward traffic to the right computer. When the outgoing datagram is sent initially the router will keep that port as the source port from the originating computer in the IP datagram, and replace only the source IP address, not the source port.
Port forwarding is another important technique used with NAT. Port forwarding means that specific destination ports can be set to always be delivered to specific nodes.
NAT, Non-Routable Address Space and the Limits of IPv4
Because there are only 4.2 billion IPv4 addresses, we are approaching the point where we “run out” of them. The IANA assigns address blocks to be allocated by regional internet registries, or RIRs. The five RIRs are AFRINIC (Africa), ARIN (the US, Canada, Caribbean), APNIC (Asia, Australia), LACNIC (Central and South America), and RIPE (Russia, Europe, Middle East and Central Asia).
Of these five regions, only AFRINIC has any IPv4 addresses left to assign, and they are expected to run out this year.
Although IPv6 will solve this problem, there is a lot of work to do before it is implemented globally. Thanks to NAT and Non-Routable Address Space (RFC1918) we are able to continue using and building the internet using IPv4.
Non-routable address space are those IP ranges that internet routers will not forward traffic to, meaning that an unlimited number of networks can use those address spaces for closed networks. With NAT and non-routable address space you can have hundreds or thousands of machines on a network with only one public-facing IPv4 address.
Supplemental Reading for IPv4 Address Exhaustion
VPNs and Proxies
Virtual Private Networks
Many organizations use something called a virtual private network to give members access to a network without physically being in a specific place. A VPN is a technology that extends a private or local network to hosts that may be outside of that local network. There are many kinds of VPN configuration, but the most common is to allow employees to access a network when they are out of the office.
VPN’s use something called a tunneling protocol, and it is common to hear the phrase “VPN tunnel.” By using a VPN client, a worker can connect to the office network by using a VPN tunnel through a virtual interface, and use an IP address that matches with the address space of the work network.
Most VPN’s use the payload section of the transport layer to carry an encrypted second set of packets. So when a datagram arrives from a VPN client the VPN server strips out the first transport layer and decrypts the payload section which actually contains the real payload for the network.
VPN’s require strict authentication procedures, often employing something called two-factor authentication, which means that a second step is required to authenticate after the name and password are accepted.
A VPN can also be set up to allow a “site to site” connection, so that two locations can use the same network resources.
It is important to remember that VPN’s are a concept, not a specific protocol, but they all employ encryption to create secure connections.
A proxy service is a server that “acts on behalf of a client in order to access another service.” A proxy sits between clients and other servers in order to provide some benefit, such as anonymity, security, content filtering or increased performance. A proxy, in this context, is a concept, not a specific implementation. There are tons of examples of proxies, but we will just go over some common ones.
A web proxy is designed for web traffic, and can serve many functions. Back when the internet was slower a web proxy server could cache a web page from the actual server, and send that to clients. This isn’t done as much anymore, because web connections are much faster and the web is a more dynamic place, such that requesting “twitter.com” will return nearly a different result for every single client because lots of people have twitter accounts.
A web proxy can also be set up to deny access to certain web sites. If a company doesn’t want people on Facebook, they could direct all web traffic to a proxy which could inspect all outgoing requests and deny any going to facebook.com.
A Reverse Proxy is a service that appears to be a single server to external clients, but represents multiple servers behind it. Many high-traffic web sites are constructed this way because there is no way for a single server to work for a huge amount of traffic.
Reverse proxies are now also used with special encryption/decryption hardware to allow web servers to only process content requests.
There are a ton of different proxies, but the important concept to remember is that a proxy is an intermediary between a client and another server.
This week’s discussion was if you think VPN’s should be illegal just because some people will use them to commit crimes. I couldn’t find any of my class mates who thought they should be. Maybe IT doesn’t attract the crass authoritarian mind.
Then came a couple more quizzes and a really easy drag and drop assignment where the “manager” asks for a certain network function and you have to drop the correct thing into the cloud.
See you next week in Connecting to the Internet
Acer Aspire AIO Touch Desktop, 23.8" Full HD Touch, Intel Core i5-7400T, 12GB DDR4, 1TB HDD, Windows 10 Home WD 4TB Black My Passport Portable External Hard Drive - USB 3.0 The Hapless Rube's Apocalypse Survival Guide by Jack Barker
One thought on “Google IT Cert – Week 10 – Network Services”