Google IT Support Certificate

There's no denying it. Computer networking is a complicated business that involves many technologies, layers, and protocols. At the end of the day, the main purpose of computer networking is so network services can be available to answer requests for the data from clients. The sheer number and variety of things that might comprise a network service makes it impossible to cover all of them. But, there are a lot of network services and technologies that are used to help make computer networking more user-friendly and secure. These network services and technologies are ones that directly relate to the business of networking itself, and it's important to understand how those work. If something on the network isn't working as expected, the first place you should look at are the services we'll be covering here. And, being asked to fix things that aren't working as expected will be a major part of being an IT support specialist. By the end of this module, you'll be able to describe why name resolution is important, identify the many steps involved with DNS lookup, and understand the most common DNS record types. You'll also be able to explain how DHCP makes network administration a simpler task. You'll be able to demonstrate how NAT technologies help keep networks secure and help preserve precious IP address space. Finally, you'll be able to describe how VPNs and proxies help users get connected and stay secure. As you can see, we've got a lot to tackle. So, let's get started. Computers speak to each other in numbers. At the very lowest levels, all computers really understand are one and zero. Reading binary numbers isn't the easiest for humans, so most binary numbers are represented in lots of different forms. This is especially true in the realm of networking. Remember that an IP address is really just a 32-bit binary number. But, it's normally written out as four octets in decimal form, since that's easier for humans to read. You might also remember that MAC addresses are just 48-bit binary numbers that are normally written out in six groupings of two hexadecimal digits each. While remembering 192.168.1.100 might be easier than remembering a long string of ones and zeros, it still doesn't do a very good job when you have to remember more than just a few addresses. Imagine having to remember the four octets of an IP address for every website you visit. It's just not a thing that the human brain is normally good at. Humans are much better at remembering words. That's where it DNS, or domain name system, comes into play. DNS is a global and highly distributed network service that resolves strings of letters into IP addresses for you. Let's say you wanted to check a weather website to see what the temperature is going to be like. It's much easier to type www.weather.com into a web browser than it is to remember that one of the IP addresses for this site is 184.29.131.121. The IP address for a domain name can also change all the time for a lot of different reasons. A domain name is just the term we use for something that can be resolved by DNS. In the example we just used, www.weather.com would be the domain name, and the IP it resolves to could change depending on a variety of factors. Let's say that weather.com was moving their web server to a new data center. Maybe they've signed a new contract, or the old data center was shutting down. By using DNS, an organization can just change what IP a domain name resolves to, and the end user would never even know. So, not only does DNS make it easier for humans to remember how to get to a website, it also lets administrative changes happen behind the scenes without an end user having to change their behavior. Try to imagine a world where you'd have to remember every IP for every website you visit, while also having to memorize new ones if something changed. We'd spend our whole day memorizing numbers. The importance of DNS for how the internet operates today can't be overstated. IP addresses might resolve to different things depending on where in the world you are. While most internet communications travel at the speed of light, the further you have to route data, the slower things will become. In almost all situations, it's going to be quicker to transmit a certain amount of data between places that are geographically close to each other. If you're a global web company, you'd want people from all over the world to have a great experience accessing your website. So, instead of keeping all of your web servers in one place, you could distribute them across data centers across the globe. This way, someone in New York visiting a website might get served by a web server close to New York, while someone in New Delhi might get served by a web server close to New Delhi. Again, DNS helps provide this functionality. Because of its global structure, DNS lets organizations decide if you're in the region, resolve the domain name to this IP. If you're in this other region, resolve this domain to this other IP. DNS serves lots of purposes and might be one of the most important technologies to understand as an IT support specialist, so you can effectively troubleshoot networking issues. At its most basic, DNS is a system that converts domain names into IP addresses. It's the way humans are likely to remember and categorize things resolved into the way computers prefer to think of things. This process of using DNS to turn a domain name into an IP address is known as name resolution. Let's take a closer look at exactly how this works. The first thing that's important to know is that DNS servers are one of the things that need to be specifically configured at a node on a network. For a computer to operate on a modern network, they need to have certain number of things configured. Remember that MAC addresses are hardcoded and tied to specific pieces of hardware. But, we've also covered that the IP address, subnet mask, and gateway for a host must be specifically configured. A DNS server is the fourth and final part of the standard modern network configuration. These are almost always the four things that must be configured for a host to operate on a network in an expected way. I should call out that a computer can operate just fine without DNS or without a DNS server being configured. But, as we covered in the last video, this makes things difficult for any human that might be using that computer. There are five primary types of DNS servers. Caching name servers, recursive name servers, root name servers, TLD name servers, and authoritative name servers. As we dive deeper into these, it's important to note that any given DNS server can fulfill many of these roles at once. Caching and recursive name servers are generally provided by an ISP or your local network. Their purpose is to store domain name lookups for a certain amount of time. As you'll see in a moment, there are lots of steps in order to perform a fully qualified resolution of a domain name. In order to prevent this from happening every single time a new TCP connection is established, your ISP or local network will generally have a caching name server available. Most caching name servers are also recursive name servers. Recursive name servers are ones that perform full DNS resolution requests. In most cases, your local name server will perform the duties of both, but it's definitely possible for a name server to be either just caching or just recursive. Let's introduce an example to better explain how this works. You and your friend are both connected to the same network, and you both want to check out facebook.com. Your friend enters www.facebook.com into a web browser, which means that their computer now needs to know the IP of www.facebook.com in order to establish a connection. Both of your computers are on the same network, which usually means that they've both been configured with the same name server. So, your friend's computer asks the name server for the IP of www.facebook.com, which it doesn't know. This name server now performs a fully recursive resolution to discover the correct IP for www.facebook.com. This involves a bunch of steps we'll cover in just a moment. This IP is then both delivered to your friend's computer and stored locally in a cache. A few minutes later, you enter www.facebook.com into a web browser. Again, your computer needs to know the IP for this domain, so your computer asks the local name server it's been configured with, which is the same one your friend's computer was just talking to. Since the domain name www.facebook.com had just been looked up, the local name server still has the IP that it resolved to stored, and is able to deliver that back to your computer without having to perform a full lookup. This is how the same servers act as a caching server. All domain names in the global DNS system have a TTL, or time to live. This is a value in seconds that can be configured by the owner of a domain name for how long a name server is allowed to cache an entry before it should discard it and perform a full resolution again. Several years ago, it was normal for these TTLs to be really long, sometimes a full day or more. This is because the general bandwidth available on the internet was just much less, so network administrators didn't want to waste what bandwidth was available to them by constantly performing full DNS lookups. As the internet has grown and gotten faster, these TTLs for most domains have dropped to anywhere from a few minutes to a few hours. But, it's important to know that sometimes you still run into a domain names with very lengthy TTLs. It means that it can take up to the length of a total TTL for a change in DNS record to be known to the entire internet. Now, let's look at what happens when your local recursive server needs to perform a full recursive resolution. The first step is always to contact a root name server. There are 13 total root name servers, and they're responsible for directing queries toward the appropriate TLD name server. In the past, these 13 root servers were distributed to very specific geographic regions. Uh but today, they're mostly distributed across the globe via anycast. Anycast is a technique that's used to route traffic to different destinations depending on factors like location, congestion, or link health. Using anycast, a computer can send a datagram to a specific IP, but can see it routed to one of many different actual destinations depending on a few factors. This should also make it clear that there aren't really only 13 physical root name servers anymore. It's better to think of them as 13 authorities that provide root name lookups as a service. The root servers will respond to a DNS lookup with the TLD name server that should be queried. TLD stands for top-level domain and represents the top of the hierarchical DNS name resolution system. A TLD is the last part of any domain name. Using www.facebook.com as an example again, the .com portion should be thought of as the TLD. We'll go into more details about the different components of a domain name in an upcoming lesson. For each TLD in existence, there's a TLD name server. But, just like with root servers, this doesn't mean there's only physically one server in question. It's most likely a global distribution of anycast accessible servers responsible for each TLD. The TLD name servers will respond again with a redirect, this time informing the computer performing the name lookup with what authoritative name server to contact. Authoritative name servers are responsible for the last two parts of any domain name, which is the resolution at which a single organization may be responsible for DNS lookups. Using www.weather.com as an example, the TLD name server would point a lookup at the authoritative server for weather.com, which would likely be controlled by the weather channel, the organization itself that runs the site. Finally, the DNS lookup could be redirected at the authoritative server for weather.com, which would finally provide the actual IP of the server in question. This strict hierarchy is very important to the stability of the internet, making sure that all full DNS resolutions go through a strictly regulated and controlled series of lookups to get the correct responses is the best way to protect against malicious parties redirecting traffic. Your computer will blindly send traffic to whatever IP it's told to. So, by using a hierarchical system controlled by trusted entities in the way DNS does, we can better ensure that the responses to DNS lookups are accurate. Now that you see how many steps are involved, it should make sense why we trust our local name servers to cache DNS lookups. It's so that full lookup path doesn't have to happen for every single TCP connection. In fact, your local computer, from your phone to a desktop, will generally have its own temporary DNS cache as well. That way, it doesn't have to bother its local name server for every TCP connection, either. DNS is a great example of an application layer service that uses UDP for the transport layer instead of TCP. This can be broken down into a few simple reasons. Remember that the biggest difference between TCP and UDP is that UDP is connectionless. This means there's no setup or tear teardown of a connection. So, much less traffic needs to be transmitted overall. A single DNS request and its response can usually fit inside of a single UDP datagram, making it an ideal candidate for a connectionless protocol. It's also worth calling out that DNS can generate a lot of traffic. It's true that caches of DNS entries are stored both on local machines and caching name servers. But, it's also true that if the full resolution needs to be processed, we're talking about a lot more traffic. Let's see what it would look like for a full DNS lookup to take place via TCP. First, the host that's making the DNS resolution request would send a SYN packet to the local name server on port 53, which is the port that DNS listens on. This name server would then need to respond with a SYN-ACK packet. That means the original host would have to respond with an ACK in order to complete the three-way handshake. That's three packets. Now that the connection has been established, the original host would have to send the actual request. I'd like the IP address for foo.com, please. When it receives this request, the name server would have to respond with another ACK. I got your request for foo.com. We're up to five packets sent now. In our scenario, the first caching name server doesn't have anything cached for foo.com. So, it needs to talk to a root name server to find out who's responsible for the .com TLD. This would require a three-way handshake, the actual request, the ACK of the request, the response, and then the ACK of the response. Oof. Finally, the connection would have to be closed via a four-way handshake. That's 11 more packets, or 16 total. Now that the recursive name server has the correct TLD name server, it needs to repeat that entire process to discover the proper authoritative name server. That's 11 more packets, bringing us up to 27 so far. Finally, the recursive name server would have to repeat the entire process one more time while talking to the authoritative name server in order to actually get the IP of foo.com. This is 11 more packets for a running total of 38. Now that the local name server finally has the IP address of foo.com, it can finally respond to the initial request. It responds to the DNS resolver that originally made the request, and then this computer sends an ACK back to confirm that it received the response. That's two more packets, putting us at 40. Finally, the TCP connection needs to be closed via a four-way handshake. This brings us to a grand total of 44 packets at the minimum in order for a fully recursive DNS request to be fulfilled via TCP. 44 packets isn't really a huge number in terms of how fast modern networks operate, but it adds up fast, as you can see. Remember that DNS traffic is just a precursor to actual traffic. A computer almost always performs a DNS lookup because it needs to know the IP of a domain name in order to send it additional data, not just because it's curious. Now, let's check out how this would look with UDP. Spoiler alert, it doesn't take as many packets. The original computer sends a UDP packet to its local name server on port 53, asking for the IP for foo.com. That's one packet. The local name server acts as a recursive server and sends up a UDP packet to the root server, which sends a response containing the proper TLD name server. That's three packets. The recursive name server sends a packet to the TLD server and receives back a response containing the correct authoritative server. We're now at five packets. Next, the recursive name server sends its final request to the authoritative name server, which sends a response containing the IP for foo.com. That's seven packets. Finally, the local name server responds to the DNS resolver that made the request in the first place with the IP for foo.com. That brings us to a grand total of eight packets. See, way less packets. You can see now how much overhead TCP really requires, and for something as simple as DNS, it's just not needed. It's the perfect example for why protocols like UDP exist in addition to the more robust TCP. You might be wondering how error recovery plays into this, since UDP doesn't have any. The answer is pretty simple. The DNS resolver just asks again if it doesn't get a response. Basically, the same functionality that TCP provides at the transport layer is provided by DNS at the application layer in the most simple manner. A DNS server never needs to care about doing anything but responding to incoming lookups. And a DNS resolver simply needs to perform lookups and repeat them if they don't succeed. A real showcase of the simplicity of both DNS and UDP. I should call out that DNS over TCP does in fact exist and is also in use all over. As the web has gotten more complex, it's no longer the case that all DNS lookup responses can fit in a single UDP datagram. In these situations, a DNS name server would respond with a packet explaining that the response is too large. The DNS client would then establish a TCP connection in order to perform the lookup. Remember, DNS is one of the most important technologies that an IT support specialist needs to know in order to troubleshoot networking issues. So, let's get into the nitty-gritty. DNS in practice operates with a set of defined resource record types. These allow for different kinds of DNS resolutions to take place. There are dozens of different resource record types defined, but a lot of them only serve very specialized purposes. We'll cover the most basic ones here. The most common resource record is known as an A record. An A record is used to point a certain domain name at a certain IPv4 IP address. In our earlier discussions of DNS, we made the assumption that the DNS resolver was asking for the A record for a domain name. In its most basic use, a single A record is configured for a single domain name. But a single domain name can have multiple A records, too. This allows for a technique known as DNS round robin to be 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. The hope is that this ensures a fairly equal balance of each entry on the list that's selected. Let's say we're in charge of a domain name www.microsoft.com. Microsoft is a large company and their website likely sees a lot of traffic. To help balance this traffic across multiple servers, we configure four A records for www.microsoft.com at the authoritative name server for the microsoft.com domain. We'll use the IPs 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4. When a DNS resolver performs a lookup of www.microsoft.com, all four IPs would be returned in the order first configured. 10.1.1.1 followed by 10.1.1.2 followed by 10.1.1.3 and finally 10.1.1.4. The DNS resolving computer would know that it should try to use the first entry, 10.1.1.1. But it knows about all four just in case a connection to 10.1.1.1 fails. The next computer to perform a lookup for www.microsoft.com would also receive all four IPs in the response, but the ordering will have changed. The first entry would be 10.1.1.2 followed by 10.1.1.3 followed by 10.1.1.4 and finally 10.1.1.1 would be last on that list. This pattern would continue for every DNS resolution attempt, cycling through all of the A records configured and balancing the traffic across these IPs. That's the basics of how DNS round robin logic works. Another resource record type that's becoming more and more popular is the quad A record. A quad A record is very similar to an A record except that it returns an IPv6 address instead of an IPv4 address. We'll cover the details of IPv6 in a future module. The CNAME record is also super common. A CNAME record is used to redirect traffic from one domain to another. Let's say that Microsoft runs their web servers at www.microsoft.com. They also want to make sure that anyone that enters just microsoft.com into their web browser will get properly redirected. By configuring a CNAME record for microsoft.com that resolves to www.microsoft.com, the resolving client would then know to perform another resolution attempt, this time for www.microsoft.com, and then use the IP returned by that second attempt. CNAMEs are really useful because they ensure you only have to change the canonical IP address of a server in one place. In fact, CNAME is just shorthand for canonical name. If we look again at our original example of making sure that visitors to both microsoft.com and www.microsoft.com get to the same place, we could do this in two ways. We could set up identical A records for both microsoft.com and www.microsoft.com domain names, and this would work just fine. But if the underlying IP address ever changes, we need to change it in two places, the A records for both microsoft.com and www.microsoft.com. By setting up a CNAME that points microsoft.com at www.microsoft.com, you'd only have to change the A record for www.microsoft.com. And you'd know that clients pointing at either domain would get the new IP address. This might not seem like a huge deal with just two records to worry about, but large companies with complex presences on the web might have dozens of these kinds of redirections. It's always easier to only have one source of truth. Another important resource record type is the MX record. MX stands for mail exchange, and this resource record is used in order to deliver email to the correct server. Many companies run their web and mail servers on different machines with different IPs. So, the MX record makes it easy to ensure that email gets delivered to a company's mail server while other traffic, like web traffic, would get delivered to their web server. A record type very similar to the MX record is the SRV record. SRV stands for service record, and it's used to define the location of very specific services. It serves the exact same purpose as the MX resource record type except for one thing. While MX is only for mail services, an SRV record can be defined to return the specifics of many different service types. For example, SRV records are often used to return the records of services like CalDAV, which is a calendar and scheduling service. The text record type is an interesting one. TXT stands for text and was originally intended to be used only for associating some descriptive text with a domain name for human consumption. The idea was that you could leave notes or messages that humans could discover and read to learn more about arbitrary specifics of your network. But over the years, as the internet and services that run on it have become more and more complex, the text record has been increasingly used to convey additional data intended for other computers to process. Since the text record has a field that's entirely free form, clever engineers have figured out ways to use it to communicate data not originally intended to be communicated by a system like DNS. It's pretty clever, right? This text record is often used to communicate configuration preferences about network services that you've entrusted other organizations to handle for your domain. For example, it's common for the text record to be used to convey additional info to an email as a service provider, which is a company that handles your email delivery for you. There are lots of other DNS resource record types in common use, like the NS or SOA records, which are used to define authoritative information about DNS zones. We'll cover DNS zones in more detail in a future video, so stay tuned. Any given domain name has three primary parts, and they all serve specific purposes. Let's take the domain name www.google.com. The three parts here should be pretty easy to spot since they're each set off from each other by a period. They're www, Google, and com. The last part of a domain name is known as the TLD or top-level domain. In this case, it's the .com portion of the domain name. There are only a certain restricted number of defined TLDs available, although that number has been growing a lot in recent years. The most common TLDs are ones you're probably already familiar with. .com, .net, .edu, and so on. You've probably also seen some country-specific TLDs, such as .de for Germany or .cn for China. Due to the growth of the internet, many of the TLDs originally defined have become very crowded. So today, a number of vanity TLDs are available, everything from .museum to .pizza. Administration and definition of TLDs is handled by a nonprofit organization known as ICANN or the Internet Corporation for Assigned Names and Numbers, and I can tell you what they do. ICANN is a sister organization to the IANA, and together they help define and control both the global IP spaces along with the global DNS system. A domain is the name commonly used to refer to the second part of a domain name, which would be Google in our example. Domains are used to demarcate where control moves from a TLD name server to an authoritative name server. This is typically under the control of an independent organization or someone outside of ICANN. Domains can be registered and chosen by any individual or company, but they must all end in one of the predefined TLDs. The www portion of this is known as the subdomain. Sometimes referred to as a host name if it's been assigned to only one host. When you combine all these parts together, you have what's known as a fully qualified domain name or FQDN. While it costs money to officially register a domain with a registrar, subdomains can be freely chosen and assigned by anyone who controls such a registered domain. A registrar is just a company that has an agreement with ICANN to sell unregistered domain names. We'll talk more about dealing with registrars in a future module. Technically, you can have lots of subdomain names. For example, host.sub.sub.subdomain.domain.com could be completely valid, although you rarely see fully qualified domain names with that many levels. DNS can technically support up to 127 levels of domain in total for a single fully qualified domain name. There are some other restrictions in place for how a domain name can be specified. Each individual section can only be 63 characters long, and a complete FQDN is limited to a total of 255 characters. [music] We've covered how authoritative name servers are responsible for responding to name resolution request for specific domains, but they do more than that. An authoritative name server is actually responsible for a specific DNS zone. DNS zones are a hierarchical concept. The root name servers we covered earlier are responsible for the root zone. Each TLD name server is responsible for the zone covering its specific TLD. And what we refer to as authoritative name servers are responsible for some even finer grain zones underneath that. The root and TLD name servers are actually just authoritative name servers, too. It's just that the zones that they're authoritative for are special cases. I should call out that zones don't overlap. For example, the administrative authority of the TLD name server for the .com TLD doesn't encompass the google.com domain. Instead, it ends at the authoritative server responsible for google.com. The purpose of DNS zones is to allow for easier control over multiple levels of a domain. As the number of resource records in a single domain increases, it becomes more of a headache to manage them all. Network administrators can ease this pain by splitting up their configurations into multiple zones. Let's imagine a large company that owns the domain largecompany.com. This company has offices in Los Angeles, Paris, and Shanghai. Very cosmopolitan. Let's say each office has around 200 people with their own uniquely named desktop computer. This would be 600 A records to keep track of if it was all configured as a single zone. What the company could do instead is split up each office into their own zone. So, now we could have la.largecompany.com, pa.largecompany.com, and sh.largecompany.com as subdomains, each with their own DNS zone. A total of four authoritative name servers would now be required for the setup. One for largecompany.com and one for each of the subdomains. Zones are configured through what are known as zone files. Simple configuration files that declare all resource records for a particular zone. So, a zone file has to contain an SOA or a start of authority resource record declaration. This SOA record declares the zone and the name of the name server that is authoritative for it. Along with the SOA record, you'll usually find NS records, which indicate other name servers that might also be responsible for this zone. For simplicity's sake, we've been referring to server in the singular when discussing what's responsible for a zone, whether at the root, TLD, or domain level. But there are often going to be multiple physical servers with their own FQDNs and IP addresses involved. Having multiple servers in place for something as important as DNS is pretty common. Why? Well, if one server were to have a problem or suffer a hardware failure, you could always rely on one of the other ones to serve DNS traffic. Besides SOA and NS records, you'll also find some or all of the other resource record types we've already covered, like A, quad A, and CNAME records, along with configurations such as default TTL values for the records served by this zone. Just like how subdomains can go many, many layers deep, zones can be configured to do this, too. But just like with subdomains, it's rare to see zones deeper than just a few levels. Sometimes, you'll also see what are known as reverse lookup zone files. These let DNS resolvers ask for an IP and get the FQDN associated with it returned. These files are the same as zone files, except instead of A and quad A records, which resolve names to IPs, you'll find mostly pointer resource record declarations. As you might have guessed, a PTR or pointer record resolves an IP to a name. Up next, a dynamic quiz for you before a dynamic new lesson on Dynamic Host Configuration Protocol. See you there. Congratulations on finishing this lesson from the Google IT Support Certificate. [music] Access the full experience including job search help and get the official certificate by clicking the icon or the link in the description. Watch the next lesson in the course by clicking here and subscribe to our channel for more lessons from upcoming [music] Google Career Certificates.