Introduction

When an application running on a Linux server needs to connect to an external service, the system must identify the correct destination and network path before sending the traffic.

For example, when a process tries to connect to a domain such as example.com, the domain name is first resolved into an IP address. After that, the Linux kernel checks its routing table to decide how the packet should be sent.

This complete process happens automatically in the background. The user or administrator does not manually run these steps during normal application communication. Commands like dig and ip route get are only used for troubleshooting and verification.

Prerequisites

Before understanding this process, it is useful to have basic knowledge of:

  • Linux networking
  • DNS resolution
  • IP addresses
  • Routing tables
  • Network interfaces
  • Gateway and source IP selection
  • Basic Linux commands such as ip, dig, nslookup, ping, and curl

How the Kernel Handles the Network Connection

Step 1: Application Starts the Connection

When an application wants to connect to a domain, it sends a connection request using the domain name.

Example:

Application wants to connect to: example.com

At this stage, the application does not directly know the destination IP address.

Step 2: DNS Resolution Happens

The system resolver checks the DNS configuration and resolves the domain name into an IP address.

Example:

example.com → 1x.1xx.2xx.3x

This DNS resolution may happen using:

  • Local DNS cache
  • /etc/hosts
  • DNS servers configured in /etc/resolv.conf
  • systemd-resolved or another DNS resolver service

Once DNS returns the IP address, the application now has the destination IP.

Step 3: Kernel Checks the Routing Table

After the destination IP is available, the Linux kernel checks the routing table to decide how to reach that IP.

Internally, the kernel performs a route lookup similar to:

ip route get <DESTINATION_IP>

For example:

ip route get 1x.1xx.2xx.3x

This command is only a manual way to view what the kernel would decide automatically.

The kernel checks:

  • Destination IP
  • Available routes
  • Default gateway
  • Outgoing interface
  • Source IP address
  • Routing rules, if any policy routing is configured

Step 4: Kernel Selects Interface, Gateway, and Source IP

Based on the routing table, the kernel selects the correct network path.

Example route decision:

Destination IP : 1x.1xx.2xx.3x
Gateway        : 192.168.1.1
Interface      : eth0
Source IP      : 192.168.1.100

This means the packet will leave the server through the eth0 interface using 192.168.1.1 as the gateway.

Step 5: Kernel Resolves the Next-Hop MAC Address

If the destination is outside the local network, the packet must be sent to the gateway.

Before sending the packet, the kernel needs the MAC address of the next hop. It checks the ARP or neighbor table.

If the MAC address is not already known, the system sends an ARP request.

Example:

Who has 192.168.1.1?

The gateway replies with its MAC address, and the kernel stores it in the ARP/neighbor table.

Step 6: Packet Is Sent Out

After the route and next-hop MAC address are known, the kernel builds the packet and sends it through the selected network interface.

The packet then travels through the gateway and network path until it reaches the destination server.

Complete Flow

Application requests connection to domain
        ↓
Domain name is resolved using DNS
        ↓
DNS returns destination IP address
        ↓
Kernel checks routing table for that IP
        ↓
Kernel selects source IP, interface, and gateway
        ↓
Kernel checks ARP/neighbor table for next-hop MAC
        ↓
Packet is sent through the selected interface
        ↓
Destination server receives the request

Example Scenario

If an application connects to:

https://example.com

The background process works like this:

example.com
   ↓
DNS resolves to 1x.1xx.2xx.3x
   ↓
Kernel checks route for 1x.1xx.2xx.3x
   ↓
Kernel selects eth0, source IP, and gateway
   ↓
Kernel sends packet through eth0

As an administrator, we can verify this behavior manually using:

dig +short example.com
ip route get 1x.1xx.2xx.3x

But in real application traffic, these steps are automatically handled by the operating system and kernel.

Important Note

The ip route get command does not perform DNS resolution. It only checks the route for an IP address.

DNS resolution happens first. Routing happens after the destination IP is known.

Correct flow:

Domain Name → DNS Resolution → Destination IP → Kernel Route Lookup → Packet Sent

Conclusion

When a process connects to a network destination, Linux automatically handles DNS resolution, route lookup, source IP selection, gateway selection, ARP lookup, and packet transmission.

The kernel does not route traffic based on the domain name directly. It routes traffic based on the destination IP address received after DNS resolution.

Commands such as dig, nslookup, and ip route get are useful for troubleshooting, but during normal application communication, the operating system performs these actions automatically in the background.

Post Views: 0

Leave a Reply