The hosts.txt file is a plain text file used to map hostnames to IP addresses, allowing for manual DNS resolution. It is commonly found in the C:\Windows\System32\drivers\etc directory on Windows systems and in /etc on Unix-based systems.

This file can be edited to override DNS settings, redirect traffic, or block access to specific websites by associating them with invalid IP addresses.

127.0.0.1       localhost
127.0.0.1       myserver.local
142.250.183.78  google.com

If you add myserver.local to the /etc/hosts file, it will direct to the IP address 127.0.0.1 whenever you access the site in a browser. Before querying a DNS server, the request will first check the /etc/hosts file. If the entry is not found, it will then proceed to query a DNS server, including any caching mechanisms in place.

Using the hosts.txt file can lead to performance issues due to the need for manual updates and potential conflicts with DNS servers. Additionally, it lacks the dynamic capabilities of DNS, making it less efficient for managing large or frequently changing networks.

Getting https://www.example.com

sequenceDiagram
    participant User as User
    participant Browser as Browser
    participant DNS as DNS Resolver
    participant Root as Root DNS Server
    participant TLD as TLD DNS Server
    participant Authoritative as Authoritative DNS Server
    participant Server as Web Server

    User->>Browser: Enter URL (https://www.example.com)
    Browser->>DNS: DNS Query for www.example.com
    DNS->>Root: Query for .com
    Root-->>DNS: Referral to TLD DNS Server
    DNS->>TLD: Query for www.example.com
    TLD-->>DNS: Referral to Authoritative DNS Server
    DNS->>Authoritative: Query for www.example.com
    Authoritative-->>DNS: IP Address of www.example.com
    DNS-->>Browser: IP Address of www.example.com
    Browser->>Server: HTTP Request to IP Address
    Server-->>Browser: HTTP Response
    Browser-->>User: Display Web Page

This entire process is done manually, so if I simply tell you what happens, you might not grasp it or agree with the concept. Let's go through each step manually to ensure we fully understand what's occurring behind the scenes.

Querying the Root Server for a example.com TLD server

To understand how DNS resolution works, let's walk through the process of resolving example.com using the dig command at each level of the DNS hierarchy. First, we query a root DNS server with:

dig example.com A @a.root-servers.net

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55436
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.            IN    A

;; AUTHORITY SECTION:
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.

;; ADDITIONAL SECTION:
l.gtld-servers.net.    172800    IN    A    192.41.162.30
l.gtld-servers.net.    172800    IN    AAAA    2001:500:d937::30
j.gtld-servers.net.    172800    IN    A    192.48.79.30
j.gtld-servers.net.    172800    IN    AAAA    2001:502:7094::30
h.gtld-servers.net.    172800    IN    A    192.54.112.30
h.gtld-servers.net.    172800    IN    AAAA    2001:502:8cc::30
d.gtld-servers.net.    172800    IN    A    192.31.80.30
d.gtld-servers.net.    172800    IN    AAAA    2001:500:856e::30
b.gtld-servers.net.    172800    IN    A    192.33.14.30
b.gtld-servers.net.    172800    IN    AAAA    2001:503:231d::2:30
f.gtld-servers.net.    172800    IN    A    192.35.51.30
f.gtld-servers.net.    172800    IN    AAAA    2001:503:d414::30
k.gtld-servers.net.    172800    IN    A    192.52.178.30
k.gtld-servers.net.    172800    IN    AAAA    2001:503:d2d::30
m.gtld-servers.net.    172800    IN    A    192.55.83.30
m.gtld-servers.net.    172800    IN    AAAA    2001:501:b1f9::30
i.gtld-servers.net.    172800    IN    A    192.43.172.30
i.gtld-servers.net.    172800    IN    AAAA    2001:503:39c1::30
g.gtld-servers.net.    172800    IN    A    192.42.93.30
g.gtld-servers.net.    172800    IN    AAAA    2001:503:eea3::30
a.gtld-servers.net.    172800    IN    A    192.5.6.30
a.gtld-servers.net.    172800    IN    AAAA    2001:503:a83e::2:30
c.gtld-servers.net.    172800    IN    A    192.26.92.30
c.gtld-servers.net.    172800    IN    AAAA    2001:503:83eb::30
e.gtld-servers.net.    172800    IN    A    192.12.94.30
e.gtld-servers.net.    172800    IN    AAAA    2001:502:1ca1::30

;; Query time: 233 msec
;; SERVER: 2001:503:ba3e::2:30#53(a.root-servers.net) (UDP)
;; WHEN: Sat Jun 07 17:03:55 IST 2025
;; MSG SIZE  rcvd: 836

This doesn't return the IP address of example.com but instead provides a list of .com TLD name servers, such as a.gtld-servers.net, b.gtld-servers.net, etc., because the root servers only know where to find Top-Level Domain (TLD) servers.

Also, note the warning indicating that recursion was requested but is not available. This occurs because a root server, such as a.root-servers.net, only provides Authoritative responses. In other words, it will not go out of its way to assist further.

A root server (like a.root-servers.net) only gives authoritative responses. It doesn’t do the dirty work for you. It just says “go ask someone else.”

But a public recursive resolver (like 1.1.1.1) is built to go all the way and bring you the final answer. It will do the full DNS resolution on your behalf.

Querying the TLD Server for example.com

dig example.com A @a.gtld-servers.net

razor@beast:~$ dig example.com A @a.gtld-servers.net

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50147
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.            IN    A

;; AUTHORITY SECTION:
example.com.        172800    IN    NS    a.iana-servers.net.
example.com.        172800    IN    NS    b.iana-servers.net.

;; Query time: 221 msec
;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net) (UDP)
;; WHEN: Sat Jun 07 17:13:19 IST 2025
;; MSG SIZE  rcvd: 88

This again doesn’t give us the final IP but tells us which authoritative name servers are responsible for example.com, specifically a.iana-servers.net and b.iana-servers.net. These servers hold the actual DNS records for the domain. Finally, we query one of these authoritative servers:

Querying the Authoritative Server

dig example.com A @a.iana-servers.net

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.iana-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49221
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.            IN    A

;; ANSWER SECTION:
example.com.        300    IN    A    23.192.228.80
example.com.        300    IN    A    23.192.228.84
example.com.        300    IN    A    23.215.0.136
example.com.        300    IN    A    23.215.0.138
example.com.        300    IN    A    96.7.128.175
example.com.        300    IN    A    96.7.128.198

;; Query time: 306 msec
;; SERVER: 2001:500:8f::53#53(a.iana-servers.net) (UDP)
;; WHEN: Sat Jun 07 17:34:36 IST 2025
;; MSG SIZE  rcvd: 136

This time, we get the desired result: a list of A records (IPv4 addresses) such as 23.192.228.80, 96.7.128.175, and others. This step-by-step resolution—from root to TLD to authoritative servers—demonstrates how DNS works behind the scenes to translate human-readable domain names into machine-usable IP addresses.

Understanding Reverse DNS Lookups

Reverse DNS lookups, involve determining the domain name associated with a given IP address. This process is the opposite of a standard DNS lookup, which resolves domain names to IP addresses, and is often used for verifying the authenticity of email servers and other network communications.

We can explore how to achieve this by utilizing the -x option with the dig command. This allows us to retrieve the domain names associated with the IP address 8.8.8.8, which is Google's DNS server.

dig -x 8.8.8.8

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47927
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN    PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.    7048    IN    PTR    dns.google.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Jun 07 17:25:35 IST 2025
;; MSG SIZE  rcvd: 73

Here is the response: as you can observe, we have obtained the dns.google domain name.

Understanding .in-addr.arpa Queries

To find reverse domain names, we perform a process similar to using dig -x. This involves querying the reverse DNS for a given IP address.

For the address 96.7.128.175, we use the command dig 175.128.7.96.in-addr.arpa.. The key step here is reversing the order of the IP address segments and appending in-addr.arpa. to the end. This reversed format is necessary because the DNS system uses this structure to map IP addresses back to domain names.

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> 175.128.7.96.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16152
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;175.128.7.96.in-addr.arpa.    IN    A

;; AUTHORITY SECTION:
in-addr.arpa.        1800    IN    SOA    ns1.reverse.deploy.akamaitechnologies.com. hostmaster.akamai.com. 1582134113 90000 90000 90000 180

;; Query time: 101 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Jun 07 17:37:40 IST 2025
;; MSG SIZE  rcvd: 149

dig -x command internally uses the .in-addr.arpa queries. To confirm this, we can examine the source code of the dig command.

isc_result_t
get_reverse(char *reverse, size_t len, char *value, isc_boolean_t ip6_int,
        isc_boolean_t strict)
{
    int r;
    isc_result_t result;
    isc_netaddr_t addr;

    addr.family = AF_INET6;
    r = inet_pton(AF_INET6, value, &addr.type.in6);
    if (r > 0) {
        /* This is a valid IPv6 address. */
        dns_fixedname_t fname;
        dns_name_t *name;
        unsigned int options = 0;

        if (ip6_int)
            options |= DNS_BYADDROPT_IPV6INT;
        dns_fixedname_init(&fname);
        name = dns_fixedname_name(&fname);
        result = dns_byaddr_createptrname2(&addr, options, name);
        if (result != ISC_R_SUCCESS)
            return (result);
        dns_name_format(name, reverse, (unsigned int)len);
        return (ISC_R_SUCCESS);
    } else {
        /*
         * Not a valid IPv6 address.  Assume IPv4.
         * If 'strict' is not set, construct the
         * in-addr.arpa name by blindly reversing
         * octets whether or not they look like integers,
         * so that this can be used for RFC2317 names
         * and such.
         */
        char *p = reverse;
        char *end = reverse + len;
        if (strict && inet_pton(AF_INET, value, &addr.type.in) != 1)
            return (DNS_R_BADDOTTEDQUAD);
        result = reverse_octets(value, &p, end);
        if (result != ISC_R_SUCCESS)
            return (result);
        /* Append .in-addr.arpa. and a terminating NUL. */
        result = append(".in-addr.arpa.", 15, &p, end);
        if (result != ISC_R_SUCCESS)
            return (result);
        return (ISC_R_SUCCESS);
    }
}

Understanding the Resolution of Subdomains

A subdomain is a distinct section of a main domain, allowing for the creation of separate websites or web services under the primary domain name. For example, "blog.example.com" is a subdomain of "example.com," enabling the hosting of a blog on a different URL while maintaining the main domain's branding.

graph TD
    A[Client] -->|DNS Query| B[Local DNS Server]
    B -->|Recursive Query| C[Root DNS Server]
    C -->|Referral| D[TLD DNS Server]
    D -->|Referral| E[Authoritative DNS Server]
    E -->|DNS Response| D
    D -->|DNS Response| C
    C -->|DNS Response| B
    B -->|DNS Response| A
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#f66,stroke-width:2px
    style C fill:#bbf,stroke:#f66,stroke-width:2px
    style D fill:#bbf,stroke:#f66,stroke-width:2px
    style E fill:#bbf,stroke:#f66,stroke-width:2px

No Delegation

In a non-delegated subdomain, the DNS records for the subdomain are managed by the parent domain's DNS servers. For instance, if blog.example.com is a non-delegated subdomain, the DNS records for blog are handled by the DNS servers responsible for example.com. This setup simplifies management but can centralize the load on the parent domain's servers.

example.com       → handled by ns1.dnsprovider.com
blog.example.com  → also handled by ns1.dnsprovider.com

Delegated Subdomain

A delegated subdomain, on the other hand, has its own set of DNS servers. For example, if blog.example.com is a delegated subdomain, it will have its own DNS servers that manage its records independently of example.com. This approach distributes the DNS load and allows for more granular control over the subdomain's DNS settings, enhancing flexibility and performance.

example.com              → handled by ns1.dnsprovider.com
internal.example.com     → delegated to ns1.internaldns.net

DNS Records Syntax

DNS records follow a specific syntax to define various types of data. The basic structure is:

• <name>: The domain name for which the record is valid.

• <ttl>: Time to Live, indicating how long the record should be cached.

• <class>: The class of the DNS data, typically IN for Internet.

• <type>: The type of DNS record, such as A, MX, CNAME, etc.

• <rdlength>: The length of the RDATA field in bytes.

• <rdata>: The actual data for the record, varying by type (e.g., IP address for A records).

This syntax ensures that DNS queries and responses are correctly interpreted by DNS servers and clients.

DNS Record Types

DNS (Domain Name System) records are essential for translating human-readable domain names into IP addresses and providing other critical information. Here are some of the most common types of DNS records:

A Record

• Purpose: Maps a domain name to an IPv4 address.

• Example: example.com. IN A 192.0.2.1

SOA Record

• Purpose: Specifies the primary name server for a domain and provides administrative information.

• Example:

    example.com. IN SOA ns1.example.com. admin.example.com. (
        2023101001 ; Serial
        3600       ; Refresh
        1800       ; Retry
        1209600    ; Expire
        3600       ; Minimum TTL
    )
  

MX Record

• Purpose: Specifies the mail servers responsible for receiving email on behalf of a domain.

• Example: example.com. IN MX 10 mail.example.com.

NS Record

• Purpose: Specifies the authoritative name servers for a domain.

• Example: example.com. IN NS ns1.example.com.

CNAME Record

• Purpose: Aliases one domain name to another.

• Example: www.example.com. IN CNAME example.com.

PTR Record

• Purpose: Maps an IPv4 address to a domain name (reverse DNS lookup).

• Example: 1.2.0.192.in-addr.arpa. IN PTR example.com.

HINFO Record

• Purpose: Provides information about the hardware and operating system of a host.

• Example: example.com. IN HINFO "PC" "Windows 10"

TXT Record

• Purpose: Holds text information for sources outside your domain.

• Example: example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

DNS Zone File

A DNS zone file is a text file that contains mappings between domain names and IP addresses, facilitating the translation of human-readable domain names into numerical IP addresses that computers use to identify each other on the network. It is organized into records, each specifying a particular type of information, such as A records for IPv4 addresses, AAAA records for IPv6 addresses, and MX records for mail servers. Zone files are essential for the functioning of the Domain Name System (DNS), enabling efficient and reliable domain name resolution across the internet.

$TTL 3600
@       IN  SOA ns1.example.com. admin.example.com. (
                2025060701 ; Serial
                3600       ; Refresh
                1800       ; Retry
                1209600    ; Expire
                86400 )    ; Minimum TTL

        IN  NS   ns1.example.com.
        IN  NS   ns2.example.com.
@       IN  A    192.0.2.1
www     IN  CNAME example.com.
mail    IN  A    192.0.2.2
@       IN  MX   10 mail.example.com.

A DNS zone file is a text file that contains mappings between domain names and IP addresses, facilitating the translation of human-readable domain names into numerical IP addresses that computers use to identify each other on a network. It is organized into records, each specifying details like the domain name, record type (e.g., A, CNAME, MX), and corresponding values. Zone files are essential for DNS servers to resolve queries efficiently and direct traffic to the correct destinations. They are typically managed by domain administrators to ensure accurate and up-to-date DNS configurations.

Attacks on DNS

Denial Of Service

Denial of Service (DoS) attacks against DNS servers aim to overwhelm the server with excessive traffic, preventing it from responding to legitimate requests. This disrupts the translation of domain names to IP addresses, causing widespread internet outages and making websites and services inaccessible.

DNS cache poisoning

DNS cache poisoning occurs when an attacker corrupts a DNS resolver's cache with false information, redirecting users to malicious websites. This manipulation can lead to various security issues, such as phishing attacks or data theft, by exploiting the trust users place in legitimate domain names.

DNSSEC

DNSSEC (Domain Name System Security Extensions) is a suite of specifications designed to enhance the security of the Domain Name System (DNS) by enabling DNS responses to be validated. It adds cryptographic signatures to DNS data, helping to protect against certain types of attacks, such as DNS spoofing and cache poisoning.

Directory Structure

.
├── build
├── include
├── Makefile
├── README.md
└── src
    └── main.c

The directory structure is organized as follows:

• build: This directory is intended to hold the compiled output of the project. It typically contains the executable files and any intermediate object files generated during the build process.

• include: This folder is used to store header files (.h) that contain declarations for the functions and variables used in the source code. These headers are included in the source files to provide necessary definitions and interfaces.

• Makefile: This file contains instructions for the build process. It defines rules and dependencies for compiling the source code into an executable program. The Makefile automates the compilation process, making it easier to build the project.

• README.md: This markdown file provides an overview of the project. It usually includes information about the project's purpose, how to set it up, how to build it, and any other relevant details that users or developers might need to know.

• src: This directory contains the source code files for the project. It is where the main implementation of the program resides.

Makefile

# Compiler
CC = gcc

# Directories
SRC_DIR = src
INC_DIR = include
BUILD_DIR = build

# Files
SRCS = $(wildcard $(SRC_DIR)/*.c)
OBJS = $(patsubst $(SRC_DIR)/%.c,$(BUILD_DIR)/%.o,$(SRCS))
TARGET = $(BUILD_DIR)/main

# Flags
CFLAGS = -I$(INC_DIR) -Wall -Wextra -g

# Rules
all: $(TARGET)
    $(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR)
    $(CC) $(CFLAGS) -c $< -o $@
    $(TARGET): $(OBJS)
    $(CC) $(CFLAGS) $^ -o $@

$(BUILD_DIR):
    mkdir -p $(BUILD_DIR)

run: $(TARGET)
    ./$(TARGET)

clean:
rm -rf $(BUILD_DIR)

.PHONY: all clean

A Makefile simplifies our workflow. Instead of typing out a lengthy command with all the necessary compiler flags or pressing the up arrow on your terminal, we can predefine the commands and execute them using simple commands like make run, make clean, etc.

Understanding File Descriptors

File descriptors are unique identifiers used by the operating system to access files or other input/output resources. They enable programs to read from or write to these resources efficiently. Each open file or resource is associated with a specific file descriptor, typically an Integer.

#include <stdio.h>
#include <fcntl.h>

int main() {

    int filefd = open("test.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (filefd < 0) {
        perror("Failed to open file");
        return 1;
    }

    printf("File descriptor: %d\n", filefd);

    return 0;
}

In this program, we open a file described by test.txt using the options O_WRONLY | O_CREAT | O_TRUNC. Here's a brief explanation of these options:

• O_WRONLY: Opens the file for writing only.

• O_CREAT: Creates the file if it does not exist.

• O_TRUNC: Truncates the file to zero length if it already exists.

These options are bitwise OR'd together. They are defined in the fcntl.h header file and are essentially binary numbers. We OR these flags and pass the resulting integer to the open system call. Additionally, we can set the file permissions to 0644, which is the same format used with the chmod command. The leading zero in 0644 signifies that the number is in octal format.

You can use Ctrl + Click on the flags to navigate to the file located at /usr/include/x86_64-linux-gnu/bits/fcntl.h.

#define O_ACCMODE       0003
#define O_RDONLY         00
#define O_WRONLY         01
#define O_RDWR             02
#ifndef O_CREAT
# define O_CREAT       0100    /* Not fcntl.  */
#endif
#ifndef O_EXCL
# define O_EXCL           0200    /* Not fcntl.  */
#endif
#ifndef O_NOCTTY
# define O_NOCTTY       0400    /* Not fcntl.  */
#endif
#ifndef O_TRUNC
# define O_TRUNC      01000    /* Not fcntl.  */
#endif
#ifndef O_APPEND
# define O_APPEND      02000
#endif
#ifndef O_NONBLOCK
# define O_NONBLOCK      04000
#endif
#ifndef O_NDELAY
# define O_NDELAY    O_NONBLOCK
#endif
#ifndef O_SYNC
# define O_SYNC           04010000
#endif
#define O_FSYNC        O_SYNC
#ifndef O_ASYNC
# define O_ASYNC     020000
#endif
#ifndef __O_LARGEFILE
# define __O_LARGEFILE    0100000
#endif

#ifndef __O_DIRECTORY
# define __O_DIRECTORY    0200000
#endif
#ifndef __O_NOFOLLOW
# define __O_NOFOLLOW    0400000
#endif
#ifndef __O_CLOEXEC
# define __O_CLOEXEC   02000000
#endif
#ifndef __O_DIRECT
# define __O_DIRECT     040000
#endif
#ifndef __O_NOATIME
# define __O_NOATIME   01000000
#endif
#ifndef __O_PATH
# define __O_PATH     010000000
#endif
#ifndef __O_DSYNC
# define __O_DSYNC     010000
#endif
#ifndef __O_TMPFILE
# define __O_TMPFILE   (020000000 | __O_DIRECTORY)
#endif

Above, you can see that we have defined an octal number, which we can pass using the | operator and send it to the open syscall.

Sockets

Introduction

Sockets are endpoints for communication between two machines. They enable data exchange over a network using protocols like TCP or UDP. Sockets are fundamental in network programming, allowing applications to send and receive data.

The primary distinction between normal file descriptors and socket descriptors lies in their binding behavior. When you use the open function in C to access a file, you receive a file descriptor that is directly bound to a specific file or device on the system. In contrast, when you create a socket and receive a file descriptor, it is not automatically bound to any port. You must manually bind the socket descriptor to a port using additional functions.

Socket Creation

In networking, socket creation is the initial step in establishing a connection between two devices. It involves generating a unique endpoint for communication, typically using a combination of IP address and port number. This process is fundamental in both client-server and peer-to-peer communication models.

// Create a socket
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
    perror("Error opening socket");
    exit(1);
}

The syntax for creating a socket is shown above. It accepts three arguments and returns a descriptor.

The initial parameter is referred to as the Protocol family. There are numerous families, including AF_INET, AF_BLUETOOTH, and AF_INET6. This parameter determines the fundamental type of socket being created. For instance, AF_INET is used for IPv4 connections.

The subsequent parameter is known as the Socket Type, with two primary options: SOCK_DGRAM and SOCK_STREAM. SOCK_DGRAM refers to datagrams, not exclusively UDP, as there are various types of datagrams, with UDP being one of them. This parameter defines a protocol class, while the specific protocol is determined by the next parameter. It's important to note that SOCK_STREAM represents an ordered, reliable stream, whereas SOCK_DGRAM signifies an unordered, unreliable stream.

The final parameter is named Protocol, and it specifies the particular protocol to be used. For instance, if we select SOCK_DGRAM, we can utilize the UDP protocol, UDPLite, or ICMPv6. It's important to note that you cannot use SOCK_STREAM with a protocol that belongs to the SOCK_DGRAM class, such as UDP or UDPLite, and vice versa.

Honestly, I'm aware that recalling protocol numbers for protocols can be challenging, and it's easy to forget or mix them up. To simplify this, we can utilize a function called getprotobyname. This function accepts the protocol name as a parameter, like tcp, and returns a protoent structure. From this structure, we can access the protocol number using protoent->p_proto.

struct protoent *proto
proto = getprotobyname('tcp')
sockfd = socket(AF_INET, SOCK_STREAM, proto->p_proto);

Binding to an Address and Port

Binding to an address and port refers to the process of assigning a specific network address and port number to a network socket. This allows a program to listen for incoming data or send data to a particular destination. It's a fundamental concept in network programming, enabling communication between different devices and applications.

int bind(int sockfd, const struct sockaddr_in *addr, socklen_t addrlen);

To utilize the bind function, we must supply it with our socket file descriptor and a structure known as sockaddr. Let's take a closer look at the sockaddr structure.

struct sockaddr_in {
    sa_family_t    sin_family;  // Always AF_INET
    in_port_t      sin_port;    // Port number (must use htons())
    struct in_addr sin_addr;    // IP address
    char           sin_zero[8]; // Padding (unused, just fill with 0s)
};

Let's proceed to construct a sockaddr_in structure.

struct sockaddr_in server_addr;

When we create it, it might contain garbage values, so we need to reset all of them to 0. We can achieve this using the memset function. We need to provide three things: the struct, the value to write, and the size.

memset(&server_addr, 0, sizeof(server_addr));

Let's configure the server address to bind to.

server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(8080);
server_addr.sin_addr.s_addr = inet_addr("0.0.0.0");

The sin_family must be set to AF_INET exclusively because we are utilizing sockaddr_in, which is designed for IPv4 communication. Therefore, no other value can be used for sin_family

sin_port This can be configured to any port, but avoid using well-known ports such as 22.

htons converts a 16-bit unsigned short from host byte order to network byte order. It ensures that the byte order is consistent across different systems when transmitting data over a network. This function is crucial for network programming to maintain data integrity.

htons -> Host to Network Short

To understand the necessity, consider that different systems may employ either little-endian or big-endian formats. However, data transmitted over networks consistently uses big-endian. Consequently, we utilize the host-to-network byte order function, commonly abbreviated as htons.

Finally, we can configure sin_addr and its parameter s_addr using inet_addr. The inet_addr function takes an IPv4 string as its parameter.

We can also configure sin_addr.s_addr to INADDR_ANY, which allows the system to accept connections on any available network interface.

IANA Port Number Ranges

There are three ranges of port numbers defined by the Internet Assigned Numbers Authority (IANA):

1. Well-Known Ports (0-1023)

   • These ports are reserved for specific protocols such as HTTP, SSH, and DNS.

   • We must avoid binding sockets to ports within this range.

2. Registered Ports (1024-49151)

   • These ports are available for use in binding and other operations.

3. Dynamic/Ephemeral Ports (49152-65535)

   • These ports are used by the system as ephemeral ports during communication.

Listening on a Socket

The listen() function in network programming is used to mark a socket as a passive socket, indicating that it will be used to accept incoming connection requests. This function is typically called on a server-side socket to enable it to listen for incoming connections from client sockets. The listen() function takes a backlog parameter, which specifies the maximum number of pending connections that can be queued before new connection requests are rejected.

listen(sockfd, 5)

The initial parameter represents the socket file descriptor, while the second parameter denotes the size of the queue.

• Returns 0 on success.

• Returns -1 on failure.

Accepting a Connection

Accepting a connection involves using the accept() function, which is typically called on a socket that is already bound to a specific port and is listening for incoming connections. This function returns a new socket file descriptor that can be used to communicate with the connected client. The accept() function is usually used in conjunction with bind() and listen() functions to set up the server socket.

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

To handle incoming connections, you need to pass the socket file descriptor to the accept function. For each accepted connection, you must store the client's sockaddr information. To achieve this, you'll need to create a new sockaddr structure and pass it along with its length as the next two parameters to the accept function.

struct sockaddr_in client_addr; 
socklen_t client_len = sizeof(client_addr);


int newsockfd = accept(sockfd, (struct sockaddr *)&client_addr, &client_len);
if (newsockfd < 0) {
    perror("accept");
    close(sockfd);
    return 1;
}

You should be aware that the accept function call is a blocking call. If you invoke the accept call, it will remain in a blocked state until a connection is received and closed.

printf("Accepted connection from %s:%d\n",
        inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port));

const char *response = "HTTP/1.1 200 OK\r\n"
                        "Content-Type: text/plain\r\n"
                        "Content-Length: 13\r\n"
                        "\r\n"
                        "Hello, World!";
write(newsockfd, response, strlen(response));
close(newsockfd);

Upon accepting a connection, the details of the connection, such as the client's IP address and port, are stored in the sockadd structure that we provided. These details can be retrieved from this structure.

Next, we'll create an HTTP 1.1 response to send back to the client. For now, we'll manually send a simple "hello world" string. Don't worry about the HTTP protocol details; it's text-based, and you can understand what's happening just by reading the response value.

Currently, we employ the write call in a manner similar to writing to any other file descriptor. We pass the file descriptor, the buffer, and the length to write.

We then terminate the connection.

curl and Check

Let's now utilize the curl command to establish a connection with the server.

razor@beast:~$ curl localhost:8080
Hello, World!

Here's what we've got: the "hello world" text displayed in the terminal. We've just created a basic HTTP server using C.

Accepting Connections with a while Loop

You may have noticed that when you attempt to use curl again, the connection fails because the server shuts down after the previous unsuccessful connection. This happens because the accept primitive is a blocking call. It listens for a connection the first time, and once it receives one, it executes the code and exits, causing the entire program to terminate. To prevent this, you can wrap the entire accept connection code in an infinite while loop.

while(1){
    struct sockaddr_in client_addr; 
    socklen_t client_len = sizeof(client_addr);


    int newsockfd = accept(sockfd, (struct sockaddr *)&client_addr, &client_len);
    if (newsockfd < 0) {
        perror("accept");
        close(sockfd);
        return 1;
    }

    printf("Accepted connection from %s:%d\n",
           inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port));

    const char *response = "HTTP/1.1 200 OK\r\n"
                           "Content-Type: text/plain\r\n"
                           "Content-Length: 13\r\n"
                           "\r\n"
                           "Hello, World!";
    write(newsockfd, response, strlen(response));
    close(newsockfd);

}

When a connection request is received, the accept call will pause and wait. Upon arrival of a connection, the associated code runs, generating a response. Due to the infinite while loop, accept is called again, causing the process to pause once more waiting for other connections.