Networking Services

At the end of the day, the main purpose is so network services can answer requests with the data from clients. There are a lot of network services that help make computer networking secure. It's important to understand how those work. The first place you should look at is these services in these articles. This article will cover name resolution, DNS lookup, and the DNS record types, as well as DHCP, NAT technologies, VPNs, and proxies.

Most binary numbers are represented in lots of different forms. An IP address is a 32-bit binary number, or as 4 octets. MAC addresses are written in 6 groupings of 2 hexadecimal digits each. Humans are much better at remembering words. Domain Name System or DNS is a global and highly distributed network service that resolves strings of letters into IP addresses for you. It's much easier to type www.weather.com vs 184.29.131.121. The IP address for a domain name (something resolved by DNS), can change over time, especially if data is going to a data center. The organization can change the IP to resolve 2 and the end-users will never even know. IP addresses can resolve different things depending on where in the world you are. It's going to be quicker to transmit data between places that are close to each other. A global web server distributes stuff across data centers across the globe. DNS lets organizations decide what domain things should be resolved to, and is one of the most important technologies to understand as an IP specialist.

DNS is a system that converts domain names into IP addresses, the way humans categorize things resolve to how computers think of things, and this process is called name resolution. DNS servers need to be specifically configured at a node on the network. MAC addresses are hardcoded and the IP address, Subnet Mac, Gateway, and DNS server must be configured for a host to operate on a network in an expected way. 

The 5 types of DNS servers are caching name servers, recursive name servers, root name servers, TLD name servers, and authoritative name servers. It's important to note that any server can fill many of these roles at once. Caching servers store domain name lookups for a certain amount of time. In order to prevent this from happening, we generally will have a caching name service available. Most caching name servers are also recursive name servers, which perform full DNS resolution requests. It's possible for a name server to be just caching or just recursive. 

Let's say you and your friend are both connected to the same network and both want to check out Facebook. The friend enters www.facebook.com which means the computer needs to know the IP to establish a connection. Both computers are on the network, and the friend's computer asks the name server for the IP of www.facebook.com. The name server performs a fully recursive search to get the link. This IP is stored locally in a cache and delivered to a friend server. Your computer asks the server, and since the domain name www.facebook.com has been looked up, the computer still has the IP.

All domain names have a TTL (time-to-live) which 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 be in the cache before it must be discarded. It was normal for these TTLs to be really long because the bandwidth was much less so network administrators don't want to perform DNS lookups. Now the TTLs drop with a few minutes to a few hours. 

The first step is to contact a root name server. These 13 root servers are distributed to Geographic regions but now distributed with AnyCast, a technique used to route traffic to different destinations depending on location, congestion, or link health. A computer can send a datagram to an id but can see a router to one of many different destinations, 13 authorities. The root service will respond to a DNS lookup with a TLD server that would be queried. A TLD is the last part of any domain name. The .com portion should be the TLD. For each TLD, there's a TLD name server and most likely a global distribution of servers for each distribution. The TLD name servers will be a redirect of what authoritative name server to contact. Authoritative name servers are responsible for the last 2 parts of the name, pointing a lookup for weather.com which will likely be controlled by the weather channel. Finally, the DNS server could be redirected to weather.com, which provides the actual IP for the server in question.  Make sure DNS resolutions go through a regulated and controlled series of lookups is the best way to prevent hackers. Using a hierarchical system controlled in the way DNS does would ensure the response of DNS lookups is accurate. We want to make sure Full Lookup Path doesn't have to happen for every single DNS collection. We don't want to bother the local name server for every TCP Connection. 

Now, let's talk about DNS and UDP. DNS uses UDP for the transport layer instead of TCP. The biggest difference between TCP and UDP is that UDP is connectionless. A single DNS request and response can fit inside a single UDP datagram. DNS can generate a LOT of traffic. Caches of DNS entries are stored in caching registers, but we're talking about a lot more traffic if the full resolution needs to be processed. 

For TCP, the host making the DNS resolution sends the SYN packet to port 53, which is the port DNS listens on. This name server responds with an SYN/ACK packet, and the host will respond with an ACK to complete a 3-way-handshake, then the host will send the request. The name server will have to respond with another ACK. There's no Cach for FOO.com, which talks to the 13 root servers (request. ack of request, response, ack of response). The connection will have to be closed with a 4-way handshake. Then the recursive name servers need to complete the same process to discover the authoritative name server. Finally, the Recursive name server will have to complete the process one more time in order to get the IP of foo.com. Now the local name server finally has the IP and finally responds to the DNS request. The computer sends an ACK to confirm the response and finally, the TCP connection is closed to a 4-way handshake (44 packets at minimum for a DNS request to be fulfilled via TCP). DNS traffic is a precursor to actual traffic. A computer needs to know the IP of a domain name in order to send additional data. 

In UDP, the computer sends a UDP packet asks for the IP of Foo.com. The local name server sends the UDP packet for the name server which sends a response for the TLD server.  The recursive name server sends the packet to the TLD server and receives a response containing the correct authoritative server. The recursive name server sends a final request to the authoritative name server, sending a response containing an IP for foo.com.  Finally, the local name server responds to the DNS resolver that made the request in the first place with the IP for foo.com. TCP requires a lot of overhead. This is why protocols like UDP exist in addition to the more robust TCP. The DNS resolver just asks again if it doesn't get a response. The same functionality TCP provides at the transport layer is provided by DNS at the application layer in the most simple manner. A DNS just responds to incoming lookups, and resolvers repeat lookups if they don't succeed. DNS over TCP exists and is in use all over. DNS name server would respond in some UDP cases that a packet is too large and would then set up a TCP connection to perform the lookup. 

Let's now talk about resource record types. DNS is one of the most important technologies that an IT specialist needs to know. DNS operates with a defined resource record type, which allows for different DNS resolutions to take place. The most common resource record is an A record which points a certain domain name to a certain IPv4 IP address. A single A-record is configured for a domain name but a single domain name can have multiple A-records. This allows for DNS round-robin, to be used to balance traffic across multiple IPs, ensuring a fairly equal balance on each entry on the list. Let's say we're in charge of www.microsoft.com. We can configure 4 A-records for this domain name to help balance traffic at the authoritative name server. We can use IPs 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4, and these results would return when a DNS resolver looks for the IP results of microsoft.com. The DNS resolving computer tries the first entry but tries to use all 4 if the first entry fails. The next computer will receive 4 IPs in response, with the first entries as 10.1.1.2 10.1.1.3, 10.1.1.4, 10.1.1.1. This cycles through and balances traffic along with IPs. Another resource type that is common is the Quad-A record, which returns an IPv6 address instead of an IPv4 address.

The CNAME record is used to redirect traffic from one domain to another. Microsoft wants to make sure microsoft.com will be redirected, configuring a CNAME record resolving to www.microsoft.com causes the resolving client to perform another resolution attempt, this time for www.microsoft.com using the IP referred by that second attempt. CNAMES ensures that you only have to change canonical IP addresses of servers in one place. If we look again at examples, we can do this in 2 ways. We can set up identical A-records for microsoft.com and www.microsoft.com, but we need to change the IP address for A-records for both microsoft.com and www.microsoft.com. We should set up a CNAME for microsoft.com and www.microsoft.com as a result. This may not seem like a huge deal, but large companies have dozens of these redirections. MX record, or mail exchange, is used in order to deliver email to the correct server. Many companies run their web and mail servers, and the MX record makes sure email gets directed to the mail server whereas other record types get delivered to other servers. 

A record type is an SRV record, or service record, which defines the location of various specific services, to be defined to return the specifics of many different service types, like calendar and scheduling. TXT is the text record type. Over the years, TXT has been increasingly used to convey additional data for other computers to process. TXT can communicate data not intended by DNS, and configuration preferences across network services. It can be used to convey additional info to an email and service provider, a company that handles your email for you. There are many other DNS resource record times, like the NS and SOA records used to defined authoritative information on DNS zones.

Any given domain name has 3 primary parts, and they all serve specific purposes. The 3 parts are www, goog, and com, and the last part of the domain name is the TLD or Top Level Domain. There are only a restricted number of defined TLDs available, but this number has been growing a lot (.com, .ge, .cn, .edu, etc.). Many TLDs have become very crowded, so now there's .pizza and .museum vanity TLDs. ICANN is the internet corporation for assigned names and numbers. ICANN defines and controls the global IP spaces as well as the global DNS systems. Domains are used to demarcate where control moves from a TLD name server to an authoritative name server. Domains must all end by all the predefined TLDs. www is known as the subdomain, sometimes considered as the host hame, and when combined, you have what's called a fully qualified domain name. Subdomains can be freely chosen and assigned by anyone who controls a domain. A registrar has an agreement with ICANN to solve the registered domain. You can have lots of subdomains like host.sub.sub.subdomain.domain.com. DNS can support up to 127 levels for a single qualified domain name. A complete FQDN is limited to a total of 255 characters. 

Authoritative name servers are responsible for name resolution request responses. They are also responsible for a specific DNS zone. Each TLD name server is responsible for the zone covering specific TLD. Authoritative name servers are responsible for finer grain zones. Zones don't overlap. .com TLD. It ends at the authoritative server possible for Google.com. DNS zones allow for easier control over multiple levels of a domain. Network managers can split certain configurations into multiple zones.

Let's imagine a large company that owns the domain largecompany.com. This company has offices in LA, Paris, and Shanghai, with 200 people with uniquely named addresses. The company can split up each office into their own zone, so we la.largecompany.com, pa.largecompany.com, and sh.largecompany.com for the offices. A total of 4 authoritative name servers will be required for the setup. One of them for the largecompany.com and the other for each of the subdomains. Zone files are simple configuration files that define all records for a particular zone. SOA, or the start of authority, declares the zone and the name of the name server that is authoritative for it. NS records indicate other name servers that might also be responsible for this zone. Having multiple servers in place for something as important as DNS is pretty common. We need to rely on many different servers to serve DNS records, there are also a lot of server resource types, like default TTL records. It's rare to see zones deeper than just a few levels.  DNS resolvers get the IP and the FQDN associated with it. These files are the same as zone files, but we'll find pointer resource record declarations here, which resolves an IP to a name.

Next, we want to go over the Dynamic Host Configuration Protocol. They have 4 things configured: An IP address, a subnet mask, a primary gateway, and a name server. Configuring them on hundreds of machines becomes super tedious. Subnet mask and gateway are the same at every node in the network, but the IP address needs to be different in every node of the network, and this is where DHCP, or Dynamic Host Configuration Protocol, comes into play. DHCP is CRITICAL to know as an IP support specialist. DHCP is an application layer protocol that automates the configuration process of hosts on a network. With DHCP a machine can query a DHCP server when the computer connects to the network, and receive all the networking configuration in one go. Not only does DHCP reduce the administrative overhead, but it also helps address the problem by having to choose what IP to assign to what machine. Very few machines have an IP that will be commonly known. The devices on a network need to know the IP of the gateway of all time. Network administrators will still need a way to connect to some devices through their IP. Without a static IP configured, it would be hard to diagnose any problems if it is malfunctioning. 

For a bunch of client devices, it's really only important that they have an IP on the right network. Using DHCP, you can configure a range of IP addresses set aside for these client devices. It solves the problem of having to maintain a list of every node on the network. Dynamic allocation is the most common way that DHCP works: 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. The IP of a computer can be different under a dynamic allocation. Automatic allocation is very similar to dynamic allocation, in that a range of IP addresses is set aside for assignment purposes. Using information, the DHCP server will assign the same IP to the same machine each time if possible. Fixed allocation requires a manually specified list of MAC addresses and their corresponding IPs. When a computer requests an IP the DHCP server looks for the MAC address in the table, and assigns the IP to the MAC address, or else it goes back to automatic or dynamic allocation. DHCP discovery can be used to configure lots of things, you can also use DHCP to assign things like NTP servers, or Network Time Protocol used to keep all of the servers in a network synchronized in time. DHCP can be used for more than just IP, subnet mask, gateway, and DNS servers. 

Now, let's see DHCP in action. DHCP is an application layer protocol, which means that it relies on the Transport, network, Data Link, and Physical Layers to operate. The entire point of DHCP is to help configure the network layer itself. DHCP discovery is the process by which a client configured to use DHCP attempts to get network configuration information. The DHCP discovery process has 4 steps:

1. Server discovery step: The DHCP client sends the DHCP to discover message out to the network, a special crafter broadcast message is formed. DHCP listens on UDP port 67 and DHP discovery messages are always sent on UDP port 68, encapsulated in a UDP datagram with a destination port of 67 and a source port of 68, which is then encapsulated in an IP datagram with a destination of 255.255.255.255 and a source IP of 0.0.0.0 which is delivered to every node in a LAN and the DHCP would receive this message if it is life. 

The DHCP server would examine its own configuration and would make a decision to run the IP address to the client. Then, the DHCP determines what IP address that it should offer to a client. This would depend on if it's configured to run with dynamic, automatic, or fixed address allocation. The response would be sent as a DHCP offer message with a source port of 67, a destination port of 68, a destination broadcast id of 255.255.255.255, and its actual IP as the source. The original client would recognize that this message is intended for itself since the DHCP has the field that specifies the MAC address for the client that sent the DHCP to discover the message, which the client machine processes this offer to see what IP is being offered to it. 

A DHCP client can reject this offer since we could have multiple DHCP servers to run on the same network and for the DHCP client to be configured to only respond to an offer for an IP range, but this is rare. The DHCP client responds to DHCP offer message with a request message ("yes, I would like to have an IP that you offer to me".). The DHCP receives the DHCP request message and responds with a DHCP acknowledgment message or an ACK. The networking stack on the client can use the configuration information to set up its own network layer configuration. All of this configuration is DHCP lease with an expiration time. Once a lease has expired, the DHCP client would need to negotiate a new lease by performing the DHCP discovery process all over again. When this is done, the DHCP can return the IP address to available IPs. 

NAT is a technique instead of a defined standard, and it's more on a high-level basis. Different operating systems have implemented the details of NAT in different ways, taking one IP address and translates it to another. They range from security safeguards to preserving the limited amounts of the available IPv4 space. NAT is a technology that allows a gateway to rewrite the source IP of an outgoing IP datagram while retaining the original IP in order to rewrite it into the response. 

Let's say we have 2 networks, with network A as 10.1.1.0/24 and network B as 192.168.1.0/24. Sitting between these networks is a router with an interface of network A and an IP of 10.1.1.1 and an interface on network B on 192.168.1.1. Computer 1 is on network A and has an IP of 10.1.1.100 and computer 2 is on network B and has an IP of 192.168.1.100. Computer 1 wants to communicate with a web server on computer 2, so it crafts an appropriate packet and sends this to its primary gateway: the router in between the 2 networks.  

Normally, a router will respect the contents of an IP datagram. Normally, a router will inspect the contents of an IP datagram, decrement the TTL by 1, recalculate the checksum, and forward the rest of the data. The NAT will rewrite the source IP address, and it will look like the datagram will originate from the router not computer 1 when the datagram is written to computer 2. Then computer 2 crafts its responses and sends its traffic to the router. NAT is hiding the IP of computer 1 from computer 2, this is known as IP masquerading. By using NAT, we can have hundreds of computers on Network A, all their IPs being translated to router bits. This is known as One-to-many NAT. 

NAT at the network layer is pretty easy to follow. One IP address is translated to another by a device. At the transport layer, several techniques come into play to make sure everything works properly. One-to-many NAT, thousands of computers can have their outbound traffic translated via NAT to a single IP. We now have hundreds of responses all directed at the same IP and the router at this IP needs to figure out which responses go to which computer. Port preservation is the simplest way to do this. This is a technique where the source port chosen by a client is the same port used by the router. Outbound connections choose a source port at random from the ephemeral port or the ports in the range 46,152 to 65,535. A router setup to NAT outbound traffic will set up what the source port is and use that to direct traffic back to the right computer.

Say there's a device with IP 10.1.1.0. It wants to establish an outbound connection and the networking stack of the operating system chooses port 51,300 for this connection. Port preservation is a technique where the source port chosen by a client is the same port used by the router. Once this outbound command gets to the router, it performs Network Address Translation and the own IP in the source address field of the IP datagram. It leaves the source port in the TCP datagram the same and stores this data internally in a table. When traffic returns to the router at port 51.300 the traffic is forwarded back to the IP 10.1.1.100. It's still possible for 2 different computers in a network to both choose the same source port at the same time. When this happens, the router selects an unused port at random to use.

Another important concept is port forwarding, a technique where specific destination ports can be configured to always be delivered to specific nodes. Port forwarding is a technique where specific destination ports can be configured to always be delivered to specific nodes. This allows for complete IP masquerading, while still having services that can respond to incoming traffic. Let's use the same network 10.1.1.0/24 to demonstrate there. Let's say there's a web server it IP of 10.1.1.5. With port forwarding, no one would have to know this IP, web clients will only need to know the external IP at the router. Any traffic directed to port 80 at 192.168.1.1 will be automatically written to 10.1.1.5. Response traffic will have the source IP rewritten to look like the external IP of the router.  This technique simplifies how external users might interact with lots of services all run by the same organization. 

Let's imagine a company with both a web server and a mail server. Both need to be accessible to the outside world, but they run on different servers with different IPs. Let's say the web server has an IP of 10.1.1.5 and the mail server has an IP of 10.1.1.6. Traffic for either of these services will be aimed at the same external IP or the same DNS name but will get delivered to entirely different internal servers due to their different destination ports. 

The next thing that I want to discuss is the NAT (NonRoutable Address Space) and the limits of IPv4. 

There are 4.2 billion possible IPv4 addresses and it's about to run out. The IANA assign address blocks to the 5 regional internet registries or RIRs. The 5 RIRs are AFRINIC (Parts of Africa), ARIN (Parts of the Caribbean), APNIC (Asia, Australia, New Zealand, Pacific Island), LAPNIC (Central and South America), and finally RIPE (Europe, Russia, Middle East, and Portions of Central Asia.). Most of these are already run out. IPv6 will resolve these but without IP addresses to assign a workaround is needed (NAT and Non-Routable Address Space, which consists of several different IP ranges that anyone can use). Internet routers won't forward traffic to it, so there is no global collision when people use these address spaces. With NAT, you can have hundreds, even thousands of machines, and all these computers can send traffic to and receive stuff from the internet with non-routable address space. 

A router with IPs can represent tons of computers. Non-routable address space will have to do until IPv6 becomes more and more common.

The next thing we want to talk about is the VPN. This is how businesses keep their networks secure. Organizations have proprietary information that needs to remain secure. One of the easiest ways to keep networks secure is to use various technologies so only the devices connected to the Local Area Network can access these resources. However, employees might be on a business trip and still need to get their work done.

Virtual Private Networks, or VPN, is a technology that allows for the extension of a private and local network to hosts that might not be on the local network. VPNs can accomplish many different things, and this helps employees offer networks. VPNs provision access to something that is not locally available. When establishing a VPN connection, you might also say that a VPN tunnel might be established. The employee can use a VPN client to establish a VPN tunnel to their company network, provisioning the computer with Virtual Interface with an IP that matches the address that they establish the network connection to. By sending data, the computer can access internal resources just like as if it is physically connected to the private network. Most VPNs use the payload section to carry an encrypted payload that uses the Network, Transport, and Application Layers to traverse the network. This payload is taken and unencrypted, and encapsulated with a proper data link layer, and sent out across the network. Also performed in inverse. VPN has strict authentication protocols to confirm proper access. 

Two-factor authentication is a technique where more than just a username and password is required to authenticate. A short-lived numerical token is generalized by a piece of hardware or software. VPNs establish site-to-site where a router from one end of the VPN tunnel establishes a connection to the router of the other VPN tunnel.  2 physically separated tunnels may be able to act as resources across the tunnel. VPNs are a general technology concept, not a protocol. The most important takeaway is that VPNs use encrypted tunnels to allow a remote computer to act as it is connected to a tunnel to which it is not physically connected. 

The next (and final) thing we discuss in this article is Proxy Services. A proxy service is a server that acts on behalf of a client in order to access another service. Proxy helps to have anonymity, security, content filtering and increased performance. A gateway meets the definition of a proxy, the concept of a proxy is a concept of abstraction, it doesn't refer to any specific implementation, working in any layer of the networking model. Most often, you'll hear "proxy" used to refer to a web proxy. They can be used for increased performance, allowing the proxy to retrieve webpage data from the internet, and it would then cache this data and then it returned the cached data. This proxy is pretty old, though.

Most organizations now have connections fast enough. www.twitter.com looks different for every person with their own Twitter account. A company may decide to access Reddit reduces productivity, allow the proxy to inspect what data, and allow or deny this request depending on which website is being accessed. A reverse proxy is a service that might appear to be a single server, but actually represents many servers living behind it. Twitter receives so much traffic and a website that popular needs many web servers to keep up with processing all incoming requests. A reverse proxy can act as a frontend for many web servers. A reverse proxy server is distributing incoming requests to lots of different physical servers, which is load balancing. Reverse proxies also deal with decryption. Reverse proxies are implemented to use hardware used specifically for cryptography, so the websites are free to just serve content. Proxies are any servers that act as an intermediary between a client and another service.