---
title: "Names without buying a domain: sslip.io in the homelab"
description: "sslip.io and nip.io in the homelab: DNS embedded in the hostname, TLS with Let's Encrypt, and the RPS fit versus Pi-hole or your own domain."
date: 2026-08-08
locale: en
url: https://escribano.dev/en/blog/007-sslip-io-homelab-dns/
---
In the [homelab access post](/blog/006-homelab-vpn-access/) the first layer was reaching the network: Tailscale, WireGuard, or OpenVPN. But getting on the LAN doesn't answer the next question: how do you call a service without memorizing IPs?

`192.168.1.47:3000` works until it doesn't. The container IP changes, you add a second service, or you want a valid TLS certificate and suddenly you need names. Editing `/etc/hosts` on every device is stone at its worst: fast for a test, unsustainable for a whole stack.

This is the middle layer many homelabs skip: pragmatic DNS with [sslip.io](https://sslip.io/) (and its conceptual predecessor, [nip.io](https://nip.io/)), names that resolve to the IP written into the hostname.

## What sslip.io is

[sslip.io](https://sslip.io/) is a public DNS service with a simple rule: if the hostname contains an IP address encoded with dashes, the answer is that IP.

| Hostname | Resolves to |
|----------|-------------|
| `192-168-0-42.sslip.io` | `192.168.0.42` |
| `app.192-168-0-42.sslip.io` | `192.168.0.42` |
| `203-0-113-7.sslip.io` | `203.0.113.7` (example public IP) |

You register nothing. You configure no DNS zone. The name is the record. nip.io follows the same principle; today both services are unified under the project maintained by [cunnie](https://github.com/cunnie/sslip.io).

For local development, demos, or a homelab that doesn't have its own domain yet, that removes a huge friction: any machine with outbound DNS can resolve the name without touching your router or running BIND.

## Why it matters in the homelab stack

Remember the order from the VPN post:

1. Network access
2. **Name resolution** ← here
3. TLS termination and reverse proxy
4. Application identity

sslip.io covers step 2 in minimal form. It doesn't replace full internal DNS (you don't get arbitrary `A` records like `grafana.lan`) but it does solve *"I want a hostname pointing at this specific IP"* without ceremony.

### What Tailscale already gives you (and doesn't)

If you use Tailscale, **MagicDNS** resolves names inside the tailnet (`minipc.tail12345.ts.net`) without sslip.io. That's operational stone with an anchor in Tailscale coordination; I covered that in the previous post.

sslip.io fits when:

* You want names inside the LAN without depending on the tailnet, other devices, guest VLANs, CI on the same network.
* You need a hostname Let's Encrypt recognizes via HTTP-01 on a public IP (or a service reachable from outside).
* You're testing a reverse proxy or self-hosted PaaS (Coolify, CapRover…) before buying a domain.

MagicDNS and sslip.io don't compete; they solve different layers. You can use both.

## TLS: why many people end up here

A valid TLS certificate requires the certificate authority to verify you control the name. With a normal domain, Caddy or Certbot handle that in minutes. Without a domain, the usual dead end was a self-signed certificate, and the browser screaming.

With sslip.io and a public IP reachable on port 80, the [HTTP-01](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) challenge works: Caddy (or nginx, or Traefik) serves on `203-0-113-7.sslip.io`, Let's Encrypt checks the token, and issues the certificate. That's the use case sslip.io's own documentation highlights.

With private IPs (`192.168.x.x`) the picture changes: Let's Encrypt can't reach your LAN from the internet. sslip.io still resolves names on the local network, but the certificate will need to be self-signed, from an internal CA, or obtained another way, for example, from inside the VPN or using a wildcard with DNS-01 and your own authoritative server, which is real scissors territory and deserves its own post.

I won't detail the `*.external-ip.sslip.io` wildcard dance with DNS-01; the [project docs](https://github.com/cunnie/sslip.io/blob/master/docs/wildcard.md) cover it. Enough to know it exists and isn't the default path.

## In the RPS framework

| Approach | RPS | What you pay | What you gain |
|----------|-----|--------------|---------------|
| Manual `/etc/hosts` | Minimum rock | Edit every machine | Zero infra |
| **sslip.io / nip.io** | Operational rock | Dependence on someone else's public DNS | Instant names, TLS possible with public IP |
| **Pi-hole / local Unbound** | Rock / paper | Operate and maintain the resolver | Local names (`*.homelab`), ad blocking, control |
| **Own domain + DNS** | Paper | Money, zone management, renewals | Brand, portability, real sovereignty |
| **MagicDNS (Tailscale)** | Operational rock | Anchor in coordination | Zero config inside the tailnet |

sslip.io is operational rock in the good sense: it solves today's naming problem without requiring a domain or your own DNS server. The cost is a soft anchor: you depend on `sslip.io` keeping resolution working and on your homelab not needing DNS records the scheme doesn't support.

A bridge to something that works while you decide whether a domain or Pi-hole is worth it, not DNS sovereignty.

### Bridges and anchors

| Decision | Type | Why |
|----------|------|-----|
| Hostname `service.IP.sslip.io` in versioned configs | Bridge | Tomorrow you switch to your own domain; the pattern is explicit |
| sslip.io DNS authority run by a third party | Anchor | If the service goes away or changes, your names stop resolving |
| [Self-hosted sslip.io DNS server](https://github.com/cunnie/sslip.io) | Bridge | Same logic, your infrastructure |
| Mixing sslip.io with Pi-hole without criteria | False rock | Two resolvers, split DNS, headaches, that's the next post |

This connects to [digital sovereignty](/blog/005-digital-sovereignty/): the data layer can live on your NAS while the name resolver is a public service you don't even own. Conscious is fine; invisible is a trap.

## When to use sslip.io

It makes sense when:

* You're building the homelab and don't want to buy a domain yet.
* You need to test HTTPS with Let's Encrypt on a public IP without DynDNS.
* A service requires a hostname instead of an IP (OAuth, cookies, WebSockets) and it's temporary.
* You want to document or share a demo without touching anyone's DNS.

Move on when:

* The service is public and professional, it deserves its own domain.
* You need dozens of arbitrary local names, Pi-hole or Unbound.
* An external resolver is unacceptable by policy, internal DNS or self-hosted domain.
* You already have Tailscale and only access from the tailnet, MagicDNS may be enough.

## Honest limitations

* Not generic DNS. You don't create `db.internal` pointing elsewhere; the name must embed the IP (except advanced wildcard tricks).
* External dependence. Not Cloudflare, but not yours either.
* Privacy. Every lookup goes out to sslip.io's resolver; on an isolated LAN that may matter.
* Aesthetics and stability. `grafana.192-168-1-47.sslip.io` isn't a product name; if the IP changes, the hostname changes.

## What comes next

sslip.io names the minimal resolution layer. The natural next step in this stack is TLS termination and HTTP routing (reverse proxy with Caddy or similar) and that's where real friction appears when you mix a local resolver (Pi-hole) with the proxy: split DNS, rebind protection, boot order. That's another post.

Application identity (OIDC, forward auth) comes after services have names and certificates.

sslip.io is operational rock with a conscious anchor: a bridge that lets you move forward without pretending you already have DNS sovereignty when you only have an elegant trick with dashes.