---
title: "Nombres sin comprar dominio: sslip.io en el homelab"
description: "sslip.io y nip.io en el homelab: DNS embebido en el hostname, TLS con Let's Encrypt, y el encaje en RPS frente a Pi-hole o dominio propio."
date: 2026-08-08
locale: es
url: https://escribano.dev/es/blog/007-sslip-io-homelab-dns/
---
En el [post sobre acceso al homelab](/blog/006-homelab-vpn-access/) la primera capa era llegar a la red: Tailscale, WireGuard u OpenVPN. Pero entrar en la LAN no responde la siguiente pregunta: ¿cómo llamas a un servicio sin memorizar IPs?

`192.168.1.47:3000` funciona hasta que no funciona. Cambia la IP del contenedor, añades un segundo servicio o quieres un certificado TLS válido y de repente necesitas nombres. Editar `/etc/hosts` en cada dispositivo es piedra de la peor clase: rápido para una prueba, insostenible para una pila entera.

Hablo de la capa intermedia que muchos homelabs saltan: DNS pragmático con [sslip.io](https://sslip.io/) (y su predecesor conceptual, [nip.io](https://nip.io/)), nombres que resuelven a la IP que llevan escrita en el hostname.

## Qué es sslip.io

[sslip.io](https://sslip.io/) es un servicio DNS público con una regla simple: si el hostname contiene una dirección IP codificada con guiones, la resolución devuelve esa IP.

| Hostname | Resuelve a |
|----------|------------|
| `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` (IP pública de ejemplo) |

No registras nada. No configuras zona DNS. El nombre es el registro. nip.io sigue el mismo principio; hoy ambos servicios están unificados bajo el proyecto mantenido por [cunnie](https://github.com/cunnie/sslip.io).

Para desarrollo local, demos o un homelab que aún no tiene dominio propio, eso elimina una fricción enorme: cualquier máquina con salida DNS puede resolver el nombre sin tocar tu router ni montar un servidor BIND.

## Por qué importa en la pila del homelab

Recuerda el orden que planteé en el post de VPN:

1. Acceso a la red
2. **Resolución de nombres** ← aquí
3. Terminación TLS y reverse proxy
4. Identidad de aplicación

sslip.io cubre el paso 2 de forma mínima. No sustituye un DNS interno completo (no tienes registros `A` arbitrarios como `grafana.lan`) pero sí resuelve el caso *"quiero un hostname que apunte a esta IP concreta"* sin ceremonia.

### Lo que Tailscale ya te da (y no te da)

Si usas Tailscale, **MagicDNS** resuelve nombres dentro de la tailnet (`minipc.tail12345.ts.net`) sin sslip.io. Eso es piedra operativa con ancla en la coordinación de Tailscale; ya lo traté en el post anterior.

sslip.io entra cuando:

* Quieres nombres dentro de la LAN sin depender de la tailnet (otros dispositivos, VLAN de invitados, CI en la misma red).
* Necesitas un hostname que Let's Encrypt reconozca vía HTTP-01 en una IP pública (o en un servicio alcanzable desde fuera).
* Estás probando un reverse proxy o un PaaS self-hosted (Coolify, CapRover…) antes de comprar dominio.

MagicDNS y sslip.io no compiten; resuelven capas distintas. Puedes usar ambos.

## TLS: el motivo por el que mucha gente llega aquí

Un certificado TLS válido exige que la autoridad de certificación verifique que controlas el nombre. Con un dominio normal, Caddy o Certbot lo resuelven en minutos. Sin dominio, el callejón sin salida habitual era certificado autofirmado, y el navegador gritando.

Con sslip.io y una IP pública alcanzable en el puerto 80, el desafío [HTTP-01](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) funciona: Caddy (o nginx, o Traefik) sirve en `203-0-113-7.sslip.io`, Let's Encrypt comprueba el token y emite el certificado. Es el caso de uso que la propia documentación de sslip.io destaca.

Con IPs privadas (`192.168.x.x`) la cosa cambia: Let's Encrypt no puede llegar a tu LAN desde internet. Ahí sslip.io sigue resolviendo nombres en la red local, pero el certificado tendrá que ser autofirmado, de una CA interna, o conseguirse por otra vía, por ejemplo, estando dentro de la VPN o usando un wildcard con DNS-01 y un servidor autoritativo propio, que es tijeras de verdad y merece su propio post.

No voy a detallar el baile del wildcard `*.external-ip.sslip.io` con DNS-01; la [documentación del proyecto](https://github.com/cunnie/sslip.io/blob/master/docs/wildcard.md) lo explica. Basta saber que existe y que no es el camino por defecto.

## En el marco RPS

| Enfoque | RPS | Qué pagas | Qué ganas |
|---------|-----|-----------|-----------|
| `/etc/hosts` manual | Piedra mínima | Editar cada máquina | Cero infra |
| **sslip.io / nip.io** | Piedra operativa | Dependencia de DNS público ajeno | Nombres al instante, TLS posible con IP pública |
| **Pi-hole / Unbound local** | Piedra / papel | Operar y mantener el resolver | Nombres locales (`*.homelab`), bloqueo de ads, control |
| **Dominio propio + DNS** | Papel | Dinero, gestión de zona, renovaciones | Marca, portabilidad, soberanía real |
| **MagicDNS (Tailscale)** | Piedra operativa | Ancla en coordinación | Cero config dentro de la tailnet |

sslip.io es piedra operativa en el sentido bueno: resuelve hoy el problema de nombres sin exigir dominio ni servidor DNS propio. El coste es una ancla blanda: dependes de que `sslip.io` siga resolviendo y de que tu homelab no necesite registros DNS que el esquema no permite.

Un puente hacia algo que funcione mientras decides si merece la pena un dominio o un Pi-hole, no soberanía DNS.

### Puentes y anclas

| Decisión | Tipo | Por qué |
|----------|------|---------|
| Hostname `servicio.IP.sslip.io` en configs versionadas | Puente | Mañana cambias a dominio propio; el patrón es explícito |
| Autoridad DNS de sslip.io operada por tercero | Ancla | Si el servicio desaparece o cambia, tus nombres dejan de resolver |
| [Servidor DNS sslip.io self-hosted](https://github.com/cunnie/sslip.io) | Puente | Misma lógica, infraestructura tuya |
| Mezclar sslip.io con Pi-hole sin criterio | Falsa piedra | Dos resolvers, split DNS, dolores de cabeza, de eso va el siguiente post |

Conecta con [soberanía digital](/blog/005-digital-sovereignty/): la capa de datos puede estar en tu NAS y el resolver de nombres en un servicio público que ni siquiera es tuyo. Consciente está bien; invisible es trampa.

## Cuándo usar sslip.io

Tiene sentido cuando:

* Estás montando el homelab y aún no quieres comprar dominio.
* Necesitas probar HTTPS con Let's Encrypt en una IP pública sin DynDNS.
* Un servicio exige hostname en lugar de IP (OAuth, cookies, WebSockets) y es una prueba temporal.
* Quieres documentar o compartir una demo sin tocar DNS de nadie.

Pasa a otra cosa cuando:

* El servicio es público y profesional, merece dominio propio.
* Necesitas docenas de nombres locales arbitrarios, Pi-hole o Unbound.
* El resolver externo es inaceptable por política, DNS interno o dominio self-hosted.
* Ya tienes Tailscale y solo accedes desde la tailnet, MagicDNS puede bastar.

## Limitaciones honestas

* No es un DNS genérico. No creas `db.internal` apuntando a otra IP; el nombre debe llevar la IP embebida (salvo trucos avanzados con wildcards).
* Dependencia externa. No es Cloudflare, pero tampoco es tuyo.
* Privacidad. Cada resolución sale a internet hacia el resolver de sslip.io; en una LAN aislada puede importar.
* Estética y estabilidad. `grafana.192-168-1-47.sslip.io` no es un nombre de producto; si la IP cambia, el hostname cambia.

## Lo que viene después

sslip.io nombra la capa de resolución mínima. El siguiente paso natural en esta pila es terminar TLS y enrutar HTTP (reverse proxy con Caddy u otro) y ahí aparecen las fricciones reales cuando mezclas resolver local (Pi-hole) con proxy: split DNS, rebind protection, órdenes de arranque. Ese es otro post.

Después vendrá identidad de aplicación (OIDC, forward auth) cuando los servicios ya tengan nombre y certificado.

sslip.io es piedra operativa con ancla consciente: un puente que te deja avanzar sin fingir que ya tienes soberanía DNS cuando solo tienes un truco elegante con guiones.