El DNS interno es una de esas piezas que parecen pequeñas hasta que empiezan a sostener demasiadas cosas.
Al principio te vale con recordar IPs. Luego pones nombres en el router. Después llega Pi-hole o AdGuard Home. Más tarde aparece Tailscale, un reverse proxy, algún certificado, una VLAN de laboratorio, otra de IoT, un NAS, Home Assistant, un par de VMs y servicios que quieres abrir desde fuera sin que toda la casa dependa de un castillo de naipes.
Y entonces pasa lo típico: desde el portátil funciona, desde el móvil no. Desde casa resuelve una IP, desde la VPN otra. El contenedor ve un nombre distinto al host. El servicio carga por HTTPS fuera de casa, pero dentro da vueltas raras. Reinicias el DNS y alguien en casa te pregunta por qué no va internet.
Ese es el momento en el que el DNS deja de ser una configuración secundaria y se convierte en infraestructura doméstica.
No hace falta montar una arquitectura de empresa para una casa. De hecho, casi siempre es mala idea. Pero sí conviene diseñar un poco. Lo justo para que el sistema sea aburrido, reconstruible y entendible dentro de seis meses.
Lo que quiero de mi DNS interno#
Mi objetivo no es tener el DNS más puro, más privado o más elegante. Quiero cinco cosas más terrenales.
La primera: nombres humanos. Prefiero abrir nas.home.arpa que recordar una IP. Más aún si estoy desde el móvil o desde una tablet.
La segunda: comportamiento consistente. Un servicio debería resolver de forma predecible desde casa, desde Tailscale y desde una VM. Si cada sitio ve una realidad distinta, tarde o temprano algo se rompe.
La tercera: tolerancia a reinicios. Si apago una VM de laboratorio, no quiero tirar internet en casa. Si reinicio el servidor DNS principal, la red debería aguantar lo básico.
La cuarta: separación entre lo doméstico y lo publicado. No todo lo que existe en casa debe tener nombre público. No todo lo que tiene nombre público debe resolver igual dentro y fuera.
La quinta: mantenimiento bajo. Si necesito tocar cinco paneles para cambiar el nombre de un servicio, el diseño está mal para una casa.
Con esos objetivos, mi diseño se vuelve bastante menos glamuroso. Y eso es bueno.
Elegir un dominio interno sin hacerse trampas#
Lo primero es dejar de usar nombres sueltos o .local como si fuera el dominio oficial del homelab.
.local tiene su sitio, pero está asociado a mDNS. Va bien para descubrimiento local de dispositivos, impresoras, altavoces y cosas similares. No lo usaría como base principal de un homelab con VLANs, VPN y servicios publicados. Puede funcionar durante meses y fallar justo en el dispositivo que más rabia da.
Para red doméstica, home.arpa me parece una opción muy razonable. Está pensada para eso, no pisa dominios públicos y deja claro que hablamos de nombres internos. Ejemplos:
- nas.home.arpa
- proxmox.home.arpa
- homeassistant.home.arpa
- paperless.home.arpa
- printer.home.arpa
Otra opción es usar un subdominio de un dominio propio, por ejemplo home.tu-dominio.com. Me gusta si ya gestionas DNS público y quieres integrar certificados, reverse proxy o split-horizon de forma limpia. Pero trae una responsabilidad: no mezclar lo interno y lo público sin querer.
Lo que no haría es inventar .lan, .home o .casa como si internet me debiera obediencia. Puede funcionar, sí. También puede chocar con algo mañana. Prefiero no depender de suerte.
Mi recomendación práctica:
- Si quieres simplicidad pura, usa home.arpa.
- Si ya tienes dominio propio y sabes lo que haces, usa un subdominio interno.
- Si estás empezando, evita .local para servicios de homelab.
No es una discusión religiosa. Es mantenimiento futuro.
Split-horizon: útil, pero con bisturí#
Split-horizon DNS significa que un mismo nombre puede resolver diferente según desde dónde preguntes. Fuera de casa, servicio.tu-dominio.com apunta a una IP pública o a un túnel. Dentro de casa, ese mismo nombre apunta a una IP privada o al reverse proxy interno.
Es una técnica muy útil. También es una fábrica de confusión si se usa sin criterio.
La ventaja es clara: puedes usar el mismo enlace estés donde estés. Abres https://servicio.tu-dominio.com desde casa, desde el móvil o desde fuera, y no tienes que pensar. Si estás dentro, el tráfico no sale a internet para volver a entrar. Si estás fuera, entra por el camino público correcto.
El problema aparece cuando tienes demasiadas excepciones. Un nombre resuelve interno en una VLAN, público en otra, distinto por Tailscale y diferente dentro de Docker. En ese punto no tienes split-horizon. Tienes multiverso DNS.
Mi regla es usar split-horizon solo para servicios que realmente cruzan frontera:
- Paneles que uso dentro y fuera.
- Servicios con app móvil.
- Herramientas familiares como fotos, documentos o domótica.
- APIs que necesitan el mismo endpoint en varios contextos.
Para lo demás, uso nombres internos claros. Si algo solo existe dentro de casa, no necesita nombre público. Si algo solo lo toca el laboratorio, no tiene que contaminar el DNS familiar.
El split-horizon debe reducir decisiones, no añadir misterio.
Un DNS principal y un segundo que no mienta#
En casa quiero que haya un DNS principal cómodo, normalmente Pi-hole o AdGuard Home, y un secundario que responda lo mismo o casi lo mismo.
Aquí mucha gente mete la pata. Configura un DNS principal con bloqueos, nombres internos y rewrites. Luego pone como secundario el DNS del router, del ISP o de Cloudflare. Parece redundancia, pero no lo es. Es comportamiento aleatorio.
Los clientes no siempre usan el primario hasta que falla. A veces consultan el secundario por su cuenta. Si el secundario no conoce tus nombres internos, tendrás fallos intermitentes. Un dispositivo resuelve nas.home.arpa. Otro no. Uno guarda caché. Otro pregunta fuera. Empieza la fiesta.
Si pongo dos DNS en DHCP, ambos deben conocer la zona interna. Pueden ser dos instancias de AdGuard Home sincronizadas, dos Pi-hole con gravedad parecida o un DNS ligero secundario con la misma zona local. Lo importante es que no se contradigan.
Si no tengo segundo DNS interno fiable, prefiero un único DNS y asumir el riesgo. Suena peor, pero falla de forma clara. Lo intermitente consume más vida.
Para internet básico, algunos routers permiten anunciarse como DNS y reenviar al servidor interno. No me entusiasma si el router es opaco. Prefiero saber dónde viven las reglas.
DHCP: el sitio donde se decide media guerra#
El DNS interno empieza en DHCP.
Puedes tener el diseño más bonito del mundo, pero si el router reparte otros DNS a los clientes, cada dispositivo hará lo que quiera. Y algunos dispositivos ya hacen bastante lo que quieren incluso cuando configuras todo bien.
En una casa real, revisaría tres cosas:
- Qué DNS entrega el DHCP principal.
- Si las VLANs entregan los mismos DNS o DNS específicos.
- Si hay dispositivos con DNS manual antiguo.
Los móviles y portátiles suelen obedecer bastante. TVs, IoT y cacharros raros pueden traer sorpresas. Algunos usan DNS hardcoded. Otros activan DNS privado. Otros cachean respuestas hasta que les apetece.
No hace falta perseguir cada rareza desde el primer día. Pero sí conviene tener una fuente de verdad. Para mí, esa fuente suele ser el router o firewall repartiendo por DHCP las IPs del DNS interno. Pi-hole o AdGuard Home se encargan de resolver, bloquear y reescribir.
Si usas VLANs, la cosa se pone interesante. La red de invitados no necesita resolver tus servicios internos. La red IoT quizá solo necesita Home Assistant y poco más. La red de laboratorio puede tener nombres propios. La red principal necesita lo doméstico.
No todo tiene que ver todo.
Reverse proxy y certificados: nombres que condicionan arquitectura#
En cuanto metes HTTPS interno, los nombres importan más.
Puedes tirar de certificados autofirmados, una CA local o certificados públicos con DNS challenge. Para casa, si ya tienes dominio propio, los certificados públicos mediante DNS challenge son cómodos. No necesitas exponer el servicio para emitir el certificado y evitas avisos feos en navegadores.
Pero eso empuja hacia nombres bajo un dominio real. Por ejemplo, app.home.tu-dominio.com o app.tu-dominio.com con split-horizon.
Aquí hay que decidir con calma. Si todos tus servicios internos usan nombres públicos con split-horizon, la experiencia es muy cómoda. También tienes que cuidar bien qué registros existen fuera y qué resuelve solo dentro.
Yo separaría así:
- Servicios familiares o que uso desde varios sitios: nombre bonito y certificado válido.
- Paneles internos delicados: nombre interno y acceso limitado por VPN.
- Laboratorio temporal: nombres internos, sin invertir demasiado.
No todo merece certificado bonito. No todo merece estar en el reverse proxy principal. A veces entrar por Tailscale a un panel interno es más sensato que publicarlo con una capa preciosa de HTTPS.
Tailscale cambia el mapa#
Tailscale simplifica muchísimo el acceso remoto, pero añade otra capa de nombres.
MagicDNS está muy bien para nodos que tienen cliente directo. Si una VM o servidor corre Tailscale, poder entrar por su nombre de tailnet es comodísimo. El problema viene cuando mezclas MagicDNS, subnet routers, DNS interno y nombres públicos sin una regla clara.
Mi criterio:
- Para servidores con cliente Tailscale, MagicDNS es cómodo.
- Para dispositivos detrás de subnet router, uso DNS interno normal.
- Para servicios con app o uso familiar, prefiero nombre estable bajo dominio o home.arpa.
- Para paneles técnicos, me vale un nombre interno si solo entro por VPN.
Lo que intento evitar es tener cuatro nombres para lo mismo y no saber cuál es el bueno. Si un servicio se llama paperless.home.arpa, paperless.tailnet, paperless.tu-dominio.com y paperless.local, algo sobra.
Los alias tienen coste mental. Pocos, claros y documentados.
Documentar sin montar una consultora#
El DNS interno necesita documentación mínima.
No una wiki de veinte páginas. Una tabla simple con:
- Nombre.
- IP o destino.
- Servicio.
- Dónde vive el registro.
- Si es interno, público o split-horizon.
- Quién depende de él.
Con eso basta para no volverte loco. Si mañana falla nas.home.arpa, sabes dónde mirar. Si migras un servicio, sabes qué nombre tocar. Si decides apagar una VM vieja, ves qué registros quedan colgando.
También me gusta tener una lista corta de decisiones:
- Dominio interno elegido.
- DNS primario y secundario.
- Quién entrega DHCP.
- Política para nombres públicos.
- Política para Tailscale.
Cinco líneas que ahorran una tarde.
Mi diseño base para una casa con homelab#
Si tuviera que montarlo desde cero hoy, haría esto:
- Router o firewall entrega por DHCP dos DNS internos.
- AdGuard Home o Pi-hole como DNS cómodo y visible.
- Segundo DNS interno con la misma zona local.
- home.arpa para servicios puramente internos.
- Subdominio propio solo para servicios con HTTPS bonito o acceso externo.
- Split-horizon limitado a servicios que lo necesitan de verdad.
- Tailscale para acceso remoto, sin convertirlo en sustituto de todo el DNS.
- Documentación mínima en una tabla.
No es perfecto. Es mantenible.
Y en una casa, mantenible gana a perfecto casi siempre.
Señales de que te estás complicando demasiado#
Hay síntomas bastante claros.
Si necesitas pensar más de diez segundos qué DNS responde a un nombre, mal.
Si tienes que revisar tres paneles para cambiar una IP, mal.
Si el móvil resuelve distinto que el portátil y no sabes por qué, mal.
Si un servicio tiene más nombres que usuarios, mal.
Si reiniciar una VM rompe internet en casa, muy mal.
El DNS interno debería aburrirte. Debería ser una pieza que tocas poco, entiendes rápido y puedes reconstruir sin buscar en veinte notas.
Conclusión: diseñar lo justo#
Diseñar DNS interno para una casa real no va de montar la infraestructura más avanzada. Va de evitar ambigüedad.
Un dominio interno claro. Un sitio donde viven los nombres. Un DHCP que reparte lo correcto. Un secundario que no contradice al primario. Split-horizon solo cuando mejora la vida. Tailscale usado como herramienta, no como excusa para no ordenar la red.
Ese es el punto que me interesa.
No quiero ganar un premio de arquitectura DNS. Quiero que Home Assistant, el NAS, las copias, los paneles y los servicios familiares funcionen sin que cada acceso sea una adivinanza.
Si tu DNS interno te obliga a pensar demasiado, no es sofisticado. Es deuda técnica con otro nombre.