Book Image

Network Programming with Rust

By : Abhishek Chanda
Book Image

Network Programming with Rust

By: Abhishek Chanda

Overview of this book

Rust is low-level enough to provide fine-grained control over memory while providing safety through compile-time validation. This makes it uniquely suitable for writing low-level networking applications. This book is divided into three main parts that will take you on an exciting journey of building a fully functional web server. The book starts with a solid introduction to Rust and essential networking concepts. This will lay a foundation for, and set the tone of, the entire book. In the second part, we will take an in-depth look at using Rust for networking software. From client-server networking using sockets to IPv4/v6, DNS, TCP, UDP, you will also learn about serializing and deserializing data using serde. The book shows how to communicate with REST servers over HTTP. The final part of the book discusses asynchronous network programming using the Tokio stack. Given the importance of security for modern systems, you will see how Rust supports common primitives such as TLS and public-key cryptography. After reading this book, you will be more than confident enough to use Rust to build effective networking software
Table of Contents (11 chapters)

How DNS works

Note that it's impossible for anyone to remember the IP address of each and every service on the internet. Fortunately, there is a protocol for that! The Domain Name Server (DNS) solves this problem by maintaining a map of a human readable hierarchical name to the IP address of the service in a distributed database. Thus, when a user enters http://www.google.com in their browser and hits the Enter key, the first step is to look up the IP address of the name www.google.com using DNS. The next figure shows the steps necessary in such a query. In this discussion, we will use the names local DNS resolver, local DNS server, and local DNS nameserver interchangeably:

How DNS works

An application that needs to resolve a name will use a system call like getaddrinfo. This essentially asks the OS to go ahead and resolve the name. This step is not shown in the figure. The next steps are as follows:

  1. Typically, each computer in a network will have a local DNS server configured in the file /etc/resolv.conf. In most cases, this points to the ISP's DNS server. This might also point to the home Wi-Fi router's DNS server. In that case, the DNS will transparently proxy requests to the ISP's DNS server. The OS will then query that server, asking the IP of the given name www.google.com.

  1. The local DNS server will, in turn, ask the same question to a pre-populated list of root name servers. These servers are maintained by ICANN and their addresses are well-known. They maintain addresses for the top level domain name servers. This means that they know the addresses of namesevers for the .com domain.
  2. In this step, the root name server replies with the addresses of TLD name servers for the .com domain. These servers maintain a list of addresses for name servers in their own domains.
  3. The local DNS server then contacts one of those and asks the same question.
  4. The TLD name server replies back with the addresses of servers in the google.com domain. An admin of the google.com domain maintains a bunch of nameservers for that domain. Those nameservers have full authority over all records in that domain, and each of those records are marked authoritative to indicate that.
  5. The local DNS server then asks one of those the same question.
  6. (Hopefully) that server does know the address of www.google.com. If it does, it prepares a response, marks it as authoritative, and sends it back to the local DNS server. The answer can also have a time to live associated with it so that the local DNS server can cache it for future use and evict it after the given time is over. If it does not, name resolution will fail and it will send back a special response called NXDOMAIN.
  7. The local DNS server then sends back the same response to the OS, which delivers it to the application. The local server marks the response as non-authoritative, indicating that it got that answer from somewhere else.

Interestingly, DNS is like asking a friend for someone's address, who then says I do not know, but I know someone who knows someone who knows someone who might know. I can find out for you! They then go and ask around and return with a reply.

DNS packets are often very small since they have a small question and answer along with some control information, and since DNS does not need very high reliability from the transport layer, this makes it an ideal candidate for using UDP (described in the next section). However, most implementations include an option to fall back to TCP if the transport is too unreliable.

DNS supports multiple record types for various things. The A record maps a name to an IPv4 address, AAAA record maps a name to a IPv6 address, and so on. Reverse lookups are supported using PTR records.