Fixing DNS Resolution Issues on Garuda Linux: A Complete Troubleshooting Guide

TL;DR: If you can reach your router but can't access websites on Garuda Linux (or any Arch-based distro), it's likely a DNS conflict between systemd-resolved and avahi-daemon. This guide shows you how to diagnose and fix it permanently.

The Problem

I recently encountered a frustrating network issue on my Garuda Linux system:

✅ Could access my router (192.168.29.1)

❌ Couldn't access any websites

❌ DNS resolution completely broken

❌ /etc/resolv.conf was empty and unwritable

The error message when trying to edit /etc/resolv.conf was particularly telling:

e166: can't open linked file for writing

This indicated that /etc/resolv.conf was a symlink pointing to ../run/systemd/resolve/stub-resolv.conf, but the target file was empty.

Root Cause Analysis

After investigation, I discovered the issue was a port conflict between two DNS services:

systemd-resolved - The modern DNS resolver for systemd-based systems

avahi-daemon - Apple's Bonjour/Zeroconf implementation for Linux

Both services were trying to use port 5353 for mDNS (multicast DNS), causing systemd-resolved to hang with the status "Processing requests..." indefinitely.

Step-by-Step Diagnosis

1. Check Network Interface Status

bash

ip addr show
nmcli device status

This confirmed my network interface was UP with a valid IP address.

2. Verify Default Gateway

bash

ip route show

Output showed: default via 192.168.29.1 ✅

3. Test DNS Resolution

bash

nslookup google.com
cat /etc/resolv.conf

The /etc/resolv.conf file was completely empty, confirming DNS was broken.

4. Check systemd-resolved Status

bash

sudo systemctl status systemd-resolved

Key findings:

Service was disabled (should be enabled)

Status showed "Processing requests..." (stuck/hanging)

Error messages about mDNS conflicts: "There appears to be another mDNS responder running"

5. Identify the Port Conflict

bash

sudo ss -tulpn | grep 5353
sudo lsof -i :5353

This revealed the smoking gun:

COMMAND    PID            USER FD   TYPE DEVICE SIZE/OFF NODE NAME
avahi-dae 1091           avahi 12u  IPv4  17005      0t0  UDP *:mdns
avahi-dae 1091           avahi 13u  IPv6  17006      0t0  UDP *:mdns
systemd-r 7031 systemd-resolve 15u  IPv4 133371      0t0  UDP *:mdns
systemd-r 7031 systemd-resolve 16u  IPv6 133372      0t0  UDP *:mdns

Both services were fighting for the same port!

The Complete Fix

Step 1: Quick Temporary Solution (Get Online First)

While diagnosing, I needed internet access, so I created a manual DNS configuration:

bash

# Remove the broken symlink
sudo rm /etc/resolv.conf

# Create manual DNS configuration
sudo tee /etc/resolv.conf << EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 192.168.29.1
EOF

This immediately restored internet access.

Step 2: Fix the Service Conflict

The core issue was both avahi-daemon and systemd-resolved trying to provide mDNS services.

Stop and Disable Avahi Completely

bash

# Stop both service and socket
sudo systemctl stop avahi-daemon.service
sudo systemctl stop avahi-daemon.socket

# Disable both
sudo systemctl disable avahi-daemon.service
sudo systemctl disable avahi-daemon.socket

# Mask them to prevent any restart
sudo systemctl mask avahi-daemon.service
sudo systemctl mask avahi-daemon.socket

Important: The mask command is crucial because avahi-daemon.socket can automatically restart the service even after it's disabled.

Verify Conflict Resolution

bash

sudo ss -tulpn | grep 5353

Now only systemd-resolved should be using port 5353.

Step 3: Configure systemd-resolved Properly

Create Optimal Configuration

bash

sudo tee /etc/systemd/resolved.conf << EOF
[Resolve]
DNS=8.8.8.8 1.1.1.1
FallbackDNS=192.168.29.1
Domains=~.
DNSSEC=no
MulticastDNS=no
LLMNR=no
Cache=yes
DNSStubListener=yes
EOF

Configuration Explanation:

DNS=8.8.8.8 1.1.1.1: Primary DNS servers (Google & Cloudflare)

FallbackDNS=192.168.29.1: Router as backup

MulticastDNS=no: Disable to avoid conflicts

LLMNR=no: Disable Link-Local Multicast Name Resolution

DNSSEC=no: Disable DNSSEC validation (often problematic)

Cache=yes: Enable DNS caching for performance

Restart and Enable Service

bash

sudo systemctl restart systemd-resolved
sudo systemctl enable systemd-resolved

Step 4: Restore Proper DNS Symlink

bash

# Remove manual resolv.conf
sudo rm /etc/resolv.conf

# Create proper symlink to systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Step 5: Verify Everything Works

bash

# Check service status (should be normal now)
sudo systemctl status systemd-resolved

# Verify resolv.conf content
cat /etc/resolv.conf

# Test DNS resolution
nslookup google.com

# Check detailed DNS status
resolvectl status

Final Results

After applying the fix, here's what a healthy system looks like:

systemd-resolved Status

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
   Active: active (running)
   Status: "Processing requests..."  # This is normal and healthy!

DNS Resolution Working

bash

$ nslookup google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.193.174

Proper resolv.conf

bash

$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by systemd-resolved
nameserver 127.0.0.53
options edns0 trust-ad
search .

Clean DNS Status

bash

$ resolvectl status
Global
  Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
  Current DNS Server: 8.8.8.8
  DNS Servers: 8.8.8.8 1.1.1.1
  Fallback DNS Servers: 192.168.29.1

Why This Happens

This issue commonly occurs on Arch-based distributions because:

Multiple DNS services: Both systemd-resolved and avahi-daemon are installed by default

Port conflicts: Both try to use port 5353 for mDNS services

Socket activation: avahi-daemon.socket can restart the service even when disabled

systemd-resolved disabled: Often comes disabled by default, requiring manual enablement

Prevention Tips

To avoid this issue in the future:

Choose one DNS solution: Don't run multiple mDNS services simultaneously

Enable systemd-resolved: Make sure it's enabled if you're using it

Monitor service conflicts: Use ss -tulpn | grep 5353 to check for port conflicts

Proper masking: Use systemctl mask instead of just disable for conflicting services

Alternative Solutions

If you prefer not to use systemd-resolved:

Option 1: Use NetworkManager's DNS

bash

sudo systemctl disable systemd-resolved
sudo systemctl mask systemd-resolved
# Configure DNS through NetworkManager
nmcli connection modify "connection-name" ipv4.dns "8.8.8.8,1.1.1.1"

Option 2: Static DNS Configuration

bash

# Make resolv.conf static and immutable
sudo tee /etc/resolv.conf << EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF
sudo chattr +i /etc/resolv.conf

Troubleshooting Commands Reference

Here's a quick reference for diagnosing DNS issues:

bash

# Check network connectivity
ping 8.8.8.8                    # Test with IP (bypasses DNS)
ip route show                   # Verify default gateway
ip addr show                    # Check interface status

# DNS-specific diagnostics
cat /etc/resolv.conf            # Check DNS configuration
nslookup google.com             # Test DNS resolution
dig google.com                  # Detailed DNS query
resolvectl status               # systemd-resolved status

# Service management
systemctl status systemd-resolved
systemctl status avahi-daemon
sudo ss -tulpn | grep 5353      # Check port 5353 usage
sudo lsof -i :5353             # Check what's using mDNS port

# Network service status
systemctl status NetworkManager
nmcli device status             # NetworkManager device status

Conclusion

DNS issues can be incredibly frustrating, but they're usually caused by service conflicts or misconfigurations. The key is systematic diagnosis:

Verify network connectivity works at the IP level

Check DNS configuration files and services

Identify service conflicts using port analysis

Choose one DNS solution and configure it properly

Test thoroughly after making changes

This particular issue—the mDNS conflict between systemd-resolved and avahi-daemon—is common on modern Linux distributions. Understanding how to diagnose and fix it will save you hours of frustration.

The solution ensures you have reliable DNS resolution with proper fallback mechanisms while avoiding the service conflicts that caused the original problem.