Refactored DNS page - changed authoritative NS to TLD NS wherever required (#148)

courses/level101/linux_networking/dns.md

@@ -1,4 +1,5 @@
 # DNS
+
 Domain Names are the simple human-readable names for websites. The Internet understands only IP addresses, but since memorizing incoherent numbers is not practical, domain names are used instead. These domain names are translated into IP addresses by the DNS infrastructure. When somebody tries to open [www.linkedin.com](https://www.linkedin.com) in the browser, the browser tries to convert [www.linkedin.com](https://www.linkedin.com) to an IP Address. This process is called DNS resolution. A simple pseudocode depicting this process looks this
 
 ```python
@@ -32,8 +33,7 @@ This line means the OS has to look up first in file (/etc/hosts) and then use DN
 
 The file /etc/hosts is of format
 
-
-IPAddress FQDN [FQDN].*
+IPAddress FQDN [FQDN].\*
 
 ```bash
 127.0.0.1 localhost.localdomain localhost
@@ -79,22 +79,22 @@ dig linkedin.com
 ..)........
 ```
 
-
 The packet capture shows a request is made to 172.23.195.101:53 (this is the resolver in /etc/resolv.conf) for linkedin.com and a response is received from 172.23.195.101 with the IP address of linkedin.com 108.174.10.10
 
-Now let's try to understand how DNS resolver tries to find the IP address of linkedin.com. DNS resolver first looks at its cache. Since many devices in the network can query for the domain name linkedin.com, the name resolution result may already exist in the cache. If there is a cache miss, it starts the DNS resolution process. The DNS server breaks “linkedin.com” to “.”, “com.” and “linkedin.com.” and starts DNS resolution from “.”. The “.” is called root domain and those IPs are known to the DNS resolver software. DNS resolver queries the root domain Nameservers to find the right nameservers which could respond regarding details for "com.". The address of the authoritative nameserver of “com.” is returned. Now the DNS resolution service contacts the authoritative nameserver for “com.” to fetch the authoritative nameserver for “linkedin.com”. Once an authoritative nameserver of “linkedin.com” is known, the resolver contacts Linkedin’s nameserver to provide the IP address of “linkedin.com”. This whole process can be visualized by running 
+Now let's try to understand how DNS resolver tries to find the IP address of linkedin.com. DNS resolver first looks at its cache. Since many devices in the network can query for the domain name linkedin.com, the name resolution result may already exist in the cache. If there is a cache miss, it starts the DNS resolution process. The DNS server breaks “linkedin.com” to “.”, “com.” and “linkedin.com.” and starts DNS resolution from “.”. The “.” is called root domain and those IPs are known to the DNS resolver software. DNS resolver queries the root domain nameservers to find the right top-level domain (TLD) nameservers which could respond regarding details for "com.". The address of the TLD nameserver of “com.” is returned. Now the DNS resolution service contacts the TLD nameserver for “com.” to fetch the authoritative nameserver for “linkedin.com”. Once an authoritative nameserver of “linkedin.com” is known, the resolver contacts Linkedin’s nameserver to provide the IP address of “linkedin.com”. This whole process can be visualized by running the following -
 
 ```bash
 dig +trace linkedin.com
 ```
 
-
 ```bash
 linkedin.com.		3600	IN	A	108.174.10.10
 ```
+
 This DNS response has 5 fields where the first field is the request and the last field is the response. The second field is the Time to Live which says how long the DNS response is valid in seconds. In this case this mapping of linkedin.com is valid for 1 hour. This is how the resolvers and application(browser) maintain their cache. Any request for linkedin.com beyond 1 hour will be treated as a cache miss as the mapping has expired its TTL and the whole process has to be redone.
 The 4th field says the type of DNS response/request. Some of the various DNS query types are
 A, AAAA, NS, TXT, PTR, MX and CNAME.
+
 - A record returns IPV4 address of the domain name
 - AAAA record returns the IPV6 address of the domain Name
 - NS record returns the authoritative nameserver for the domain name
@@ -123,6 +123,7 @@ dns1.p09.nsone.net.
 dig www.linkedin.com CNAME +short
 2-01-2c3e-005a.cdx.cedexis.net.
 ```
+
 Armed with these fundamentals of DNS lets see usecases where DNS is used by SREs.
 
 ## Applications in SRE role
@@ -136,8 +137,3 @@ This section covers some of the common solutions SRE can derive from DNS
 5. SRE also has to understand since there is no verification in DNS infrastructure, these responses can be spoofed. This is safeguarded by other protocols like HTTPS(dealt later). DNSSEC protects from forged or manipulated DNS responses.
 6. Stale DNS cache can be a problem. Some [apps](https://stackoverflow.com/questions/1256556/how-to-make-java-honor-the-dns-caching-timeout) might still be using expired DNS records for their api calls. This is something SRE has to be wary of when doing maintenance.
 7. DNS Loadbalancing and service discovery also has to understand TTL and the servers can be removed from the pool only after waiting till TTL post the changes are made to DNS records. If this is not done, a certain portion of the traffic will fail as the server is removed before the TTL.
-
-
-
-
-