En el post sobre acceso al homelab 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 (y su predecesor conceptual, nip.io), nombres que resuelven a la IP que llevan escrita en el hostname.

Qué es sslip.io

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.

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.

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 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 lo explica. Basta saber que existe y que no es el camino por defecto.

En el marco RPS

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

Conecta con soberanía digital: 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.