I’ve been on a laptop that plugs into a home router that sometimes hands out a DHCP lease and other times uses a static IP you set in the admin UI. The VPN client (OpenVPN 3‑CLI on Ubuntu 24.04) would drop the tunnel as soon as the interface lost its address, forcing me to reconnect manually. Below is a minimal, reproducible setup that keeps the tunnel up regardless of the router’s mode.
[Read More]I was running a Pi‑4‑based home‑lab that hosts a few services: a personal Git server, a small reverse‑proxy stack, and a few IoT sensors that ping the Pi every few seconds. Every time I pinged a domain that wasn’t in the local cache, I noticed a ~2 s pause before the first packet left the network interface. On a desktop that latency was negligible, but on the Pi it was a noticeable hiccup that made the sensor logs look a little jittery.
[Read More]I was in the middle of setting up a tiny homelab VM that bridges straight to the host. The guest could ping the gateway just fine, but ip addr show br0 was staring back at me with no inet line. The bridge was up, state UP, yet no IPv4. What’s going on?
ip link only tells you about the link layer. An interface can be physically up and still have no IP if the DHCP client never got a lease or a static config never ran.
I’ve been juggling a Plex server, Nextcloud, and a little Go API all on the same Ubuntu 24.04 box. The goal was simple: a tidy public URL for each service, automatic HTTPS, and as little upkeep as possible. Caddy 2.7 fit the bill perfectly—its ACME integration is a one‑liner, and it ships with HTTP/2 out of the box.
sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] \
https://dl.cloudsmith.io/public/caddy/stable/deb/debian any main" | \
sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
Caddy boots as a systemd service automatically. Just double‑check that it’s listening on the web ports:
[Read More]I was staring at a blinking screen of a freshly flashed router when I realized the whole LAN had lost its DNS mojo. I could ping 192.168.1.1 fine, but curl example.com slammed back with “Could not resolve host”. No amount of dig or nslookup helped until I dug into systemd‑resolved.
systemd‑resolved is the default resolver on most recent distros. It keeps a cache of answers to cut down on DNS traffic and speed things up. The cache is keyed by the DNS server that answered and the TTL that server advertised. When a router’s firmware changes, its DHCP server may hand out a new DNS IP or a new list of servers. systemd‑resolved will keep the old server in memory until it gets a fresh lease or the cache expires. If the new server is unreachable, all lookups die.
[Read More]I’ve always been curious about how my Linux system resolves domain names. Recently, I’ve been dealing with some DNS resolution issues at home, which led me to dig into systemd-resolved. As it turns out, many Linux distributions, including Ubuntu and Fedora, use systemd-resolved as their DNS resolver by default. In this article, I’ll share my experience with getting reliable DNS resolution at home using systemd-resolved.
systemd-resolved is part of the systemd suite and provides a DNS resolver service. It’s designed to be a caching, validating, and recursive DNS resolver - which means it can cache DNS responses, validate DNSSEC records, and perform recursive DNS lookups. To check if systemd-resolved is running on your system, you can use the following command:
I’ve been dealing with DNS lookup failures on my home network, and I’ve found that the systemd-resolved cache can be a major culprit. I’ve seen this go wrong when the cache becomes outdated or corrupted, leading to frustrating DNS lookup failures. In this article, I’ll share my experience with taming the systemd-resolved cache to fix these issues.
The real trick is to understand how the systemd-resolved cache works. It’s designed to improve DNS lookup performance by storing recent queries and their results. However, this cache can become outdated or corrupted, leading to DNS lookup failures. To get a better understanding of the cache, let’s take a look at the systemd-resolved configuration file, usually located at /etc/systemd/resolved.conf. You can view the file using the following command:
I’ve seen this go wrong when working with Linux systems - systemd-resolved taking over your DNS settings without warning. As a Linux user, you’re likely familiar with the resolv.conf file, which contains the DNS resolver configuration for your system. However, with the introduction of systemd-resolved, things have changed. systemd-resolved is a systemd service that provides DNS resolution and caching, and it can sometimes override the settings in your resolv.conf file. In this article, we’ll explore how to tame systemd-resolved and prevent it from overriding your resolv.conf settings.
I’ve been working with Podman for a while now, and I’ve found that networking issues can be a real pain point. When containers can’t communicate with each other or the host machine, it’s frustrating and can cause downtime. In this article, I’ll show you how to use the ss and nftables commands to troubleshoot Podman container networking issues.
Before we dive into troubleshooting, it’s essential to understand how Podman handles networking. By default, Podman uses a bridge network, which allows containers to communicate with each other and the host machine. You can verify this by running podman network ls, which lists all available networks.
I’ve been running my homelab for years, and one thing that still gets me is DNS troubles. Last year, I decided to set up systemd-resolved and dnsmasq to manage my home network’s DNS. The idea was to use systemd-resolved as the primary resolver and dnsmasq as a caching layer to improve performance. Sounds simple, but it didn’t quite work out that way.
To start, I enabled systemd-resolved on my Ubuntu-based server. This involved editing the /etc/systemd/resolved.conf file to set the DNS servers and domains. I opted for Cloudflare’s DNS servers - they’re known for being fast and secure.