This course is designed to provide a full overview of computer networking. We’ll cover everything from the fundamentals of modern networking technologies and protocols to an overview of the cloud to practical applications and network troubleshooting.
By the end of this course, you’ll be able to:
● describe computer networks in terms of a five-layer model
● understand all of the standard protocols involved with TCP/IP communications
● grasp powerful network troubleshooting tools and techniques
● learn network services like DNS and DHCP that help make computer networks run
● understand cloud computing, everything as a service, and cloud storage

Avis

AM

what an amazing course, so much information and yet so easy to understand, would recommend going over a few of the videos and supplemental reading a few times, take the time needed, it'll be worth it.

AA

Mar 26, 2020

Filled StarFilled StarFilled StarFilled StarFilled Star

Great course. It is great for beginners and for people that may have forgotten a thing or two. The way it was taught makes it so much better than reading man pages or something else as dry and boring.

À partir de la leçon

Networking Services

In the fourth week of this course, we'll explore networking services. We'll learn about why we need DNS and how it works. We'll also show you why DHCP makes network administration a simpler task. By the end of this module, you'll be able to do describe how DNS and DHCP work, how NAT technologies help keep networks secure, and how VPNs and proxies help users connect and stay secured.

Enseigné par

Google

Transcription

We've covered how authoritative name servers are responsible for responding to name resolution requests 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-grained 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 zones. 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 may 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 its 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.