TPTito Pinardo Gutiérrez
← Volver al rack
English
1U · DNSTechnitium · DoH · IP dinámica En producción

Posición 4 de 25 en el rack · En producción

Unidad 1U · Red de casa

DNS de casa · Technitium

Migrado con 0 consultas perdidas

Todos los equipos de casa, el router y el propio servidor preguntan aquí qué dirección tiene cada nombre. Responde los nombres internos, bloquea publicidad y rastreadores, valida las firmas DNSSEC y lo que tiene que preguntar fuera lo pregunta cifrado.

Por qué Technitium
Sustituye a dos piezas (Pi-hole y Unbound) con una: resolución propia, caché persistente, bloqueo y zonas locales, todo con una API.
Cómo se migró
Junto al anterior, en el mismo contenedor y la misma IP. Una redirección del puerto movió las consultas nuevas al servicio nuevo mientras las viejas terminaban.
El otro inquilino
Un contenedor diminuto comprueba cada 5 minutos la IP pública de casa y, si cambia, actualiza Cloudflare.
  • 1.200consultas durante el cambio, 0 fallos
  • 19,5 msla respuesta más lenta de esa prueba
  • 276.000+dominios en las listas de bloqueo
  • 5 mincada cuánto se comprueba la IP pública

Su código, en abierto Versión pública del repositorio: sin IPs ni secretos.

El DNS por dentro

Cada nombre que se escribe en casa pasa por aquí antes de ir a ningún sitio. Elige un recorrido.

Recorridos Pulsa uno y sigue el paquete.

Fuera Contenedores del DNS · Proxmox Technitium + sincronizador de IP Resolver Filtrar y validar La migración desde Pi-hole IP dinámica y arranque Equipos de casa DHCP del router Hipervisor DNS públicos Cloudflare Puerto 53 Zonas locales Caché DNS sobre HTTPS Listas Bloqueos propios DNSSEC Panel Pi-hole Puerto nuevo Redirección Vigilancia Sincronizador IP pública Registros Arranca primero
Hermesde visita en la unidad

Pulsa una pieza o elige un recorrido. Si vienes de una habilidad, ya están encendidas las piezas donde la uso.

      Alguien abre una web
      1. Equipos de casa — Un móvil de casa quiere abrir una web.
      2. DHCP del router — Usa el DNS que le dio el router al conectarse: este.
      3. Entrada DNS — La consulta llega al servidor DNS.
      4. Listas de bloqueo — Primero, ¿está en alguna lista de bloqueo? No.
      5. Caché persistente — ¿Está en caché? No: es la primera vez que alguien lo pide.
      6. Salida cifrada (DoH) — Sale a preguntar fuera, por HTTPS.
      7. Resolutores públicos — Un resolutor público responde.
      8. Salida cifrada (DoH) — La respuesta vuelve cifrada y se valida la firma DNSSEC si la tiene.
      9. Caché persistente — Se guarda en caché para la próxima vez.
      10. Equipos de casa — El móvil recibe la dirección y abre la web.
      Un nombre interno
      1. Equipos de casa — Desde casa pido un panel por su nombre interno.
      2. Entrada DNS — La consulta llega al DNS.
      3. Zonas locales — El nombre está en una zona local: se responde aquí mismo, sin preguntar fuera.
      4. Equipos de casa — El equipo recibe la dirección de la puerta interna.
      Una web intenta cargar publicidad
      1. Equipos de casa — Una web pide un dominio de publicidad.
      2. Entrada DNS — La consulta llega al DNS.
      3. Listas de bloqueo — Está en las listas de bloqueo.
      4. Bloqueos manuales — O en los bloqueos propios.
      5. Equipos de casa — La respuesta es «no existe»: el anuncio no carga, en ningún equipo de la casa.
      La migración, sin cortar
      1. El DNS anterior — Pi-hole sigue respondiendo a todo el mundo.
      2. Technitium en otro puerto — Technitium arranca en otro puerto del mismo contenedor y lo pruebo: nombres, bloqueos, DNSSEC.
      3. Redirección con nftables — Una regla de nftables manda las conexiones nuevas del 53 al servidor nuevo, sin cambiar IP ni nada en los clientes.
      4. Entrada DNS — Las consultas nuevas ya las responde Technitium.
      5. Monitorización — Durante cinco minutos lanzo 1.200 consultas alternando nombres externos e internos: 0 fallos, la más lenta 19,5 ms.
      6. El DNS anterior — Pi-hole se para cuando terminan sus últimas conexiones, y se queda instalado como vuelta atrás.
      Cambia la IP de casa
      1. Sincronizador de IP — Cada 5 minutos el sincronizador se despierta.
      2. ¿Cuál es mi IP? — Pregunta qué IP pública tiene casa.
      3. Resolutores públicos — La respuesta llega desde fuera.
      4. Sincronizador de IP — Ha cambiado respecto a la última vez.
      5. DNS de Cloudflare — Actualiza Cloudflare.
      6. Registros públicos — Los registros que deben apuntar a casa ya tienen la IP nueva.
      Vuelve la luz
      1. El hipervisor y sus contenedores — Tras un corte de luz, el servidor arranca. Con las comprobaciones de disco puede tardar más de una hora.
      2. Orden de arranque — El DNS tiene el primer puesto en el orden de arranque.
      3. Entrada DNS — En cuanto responde, el resto de contenedores ya pueden resolver nombres.
      4. El hipervisor y sus contenedores — El hipervisor le pregunta a él primero, y a un público solo si no responde.
      5. Equipos de casa — Mientras tanto, los equipos de casa pueden poner un DNS público a mano: no se fuerza nada en el router.
      6. DHCP del router — Cuando todo vuelve, el DHCP sigue repartiendo este DNS.

      1. Equipos de casa

        Móviles, portátiles, la tele y los contenedores del servidor: todos preguntan aquí.

      2. DHCP del router

        Al dar dirección a un equipo, el router le dice qué DNS usar: este, en los tres segmentos.

        • MikroTik

      3. El hipervisor y sus contenedores

        El servidor también resuelve aquí desde octubre, con un público de respaldo por si este no responde.

        • Proxmox VE

      4. Resolutores públicos

        Lo que no está en caché se pregunta fuera, por HTTPS.

      5. DNS de Cloudflare

        Donde viven los registros públicos de mis dominios.

      6. Entrada DNS

        La misma dirección de siempre: los equipos no notaron el cambio de servidor.

        • Technitium DNS

      7. Zonas locales

        Los nombres internos del homelab y del laboratorio. Nunca se preguntan fuera.

        • Technitium DNS

      8. Caché persistente

        Guarda las respuestas respetando su caducidad, sobrevive a reinicios y renueva antes de tiempo las más usadas.

        • Technitium DNS

      9. Salida cifrada (DoH)

        Las consultas que salen de casa van por HTTPS: quien mire la línea no ve qué nombres se piden. Comprobado: nada sale ya por el puerto 53.

        • Technitium DNS
        • Linux / SSH hardening

      10. Listas de bloqueo

        Las mismas doce listas que tenía en Pi-hole, más de 276.000 dominios de publicidad y rastreo.

        • Technitium DNS

      11. Bloqueos manuales

        Unos pocos dominios bloqueados a mano y las señales que algunos navegadores consultan para saltarse el DNS de la red.

        • Technitium DNS

      12. Validación DNSSEC

        Si un dominio firmado responde con una firma que no cuadra, la respuesta se rechaza.

        • Technitium DNS
        • Linux / SSH hardening

      13. Panel de administración

        Solo desde dentro, detrás de la puerta interna con doble factor. El servicio no corre como root.

        • Linux / SSH hardening

      14. El DNS anterior

        Pi-hole con Unbound. Se quedó instalado, parado, como vuelta atrás.

      15. Technitium en otro puerto

        El servidor nuevo arrancó junto al viejo, escuchando en otro puerto, para probarlo sin tocar a nadie.

        • Linux (Debian, Alpine, Arch)

      16. Redirección con nftables

        Una regla movió las conexiones nuevas del puerto 53 al servidor nuevo dentro del mismo contenedor. Las que ya estaban abiertas terminaron en el viejo.

        • Linux (Debian, Alpine, Arch)

      17. Monitorización

        Zabbix comprueba que resuelve nombres externos y que los dos servicios están activos; Wazuh vigila los cambios en la configuración.

      18. Sincronizador de IP

        Un contenedor mínimo con un script. Comprueba la IP pública de casa cada 5 minutos.

        • Linux (Debian, Alpine, Arch)

      19. ¿Cuál es mi IP?

        Pregunta fuera qué IP ve el mundo y la compara con la última conocida.

        • Linux (Debian, Alpine, Arch)

      20. Registros públicos

        Si la IP cambió, actualiza los registros que deben apuntar a casa. Si no, no hace nada.

      21. Orden de arranque

        Tras un corte de luz, el DNS es el primer contenedor en arrancar: el resto lo necesita.

        • Proxmox VE

      Lo que uso de mi árbol

      Pulsa una habilidad: se encienden en el mapa las piezas donde la uso y te cuento para qué.

      Proxmox VE
      El hipervisor y sus contenedores resuelven aquí, y el DNS es el primero en el orden de arranque.
      LXC
      Technitium y el sincronizador corren en sus propios contenedores LXC.
      Linux (Debian, Alpine, Arch)
      nftables para la redirección de la migración y para proteger los puertos nuevos; el servicio corre sin root con las restricciones de systemd.
      MikroTik
      El DHCP del router anuncia este DNS en los tres segmentos, y el propio router también le pregunta.
      Technitium DNS
      Technitium: zonas locales, caché persistente con prefetch, DNSSEC, minimización de consultas, listas de bloqueo y salida por DoH.
      Linux / SSH hardening
      Panel solo detrás de la puerta interna con doble factor, consultas externas cifradas y validación de firmas.

      Bitácora de incidencias

      Averías reales. Lee el síntoma, elige la causa que creas y mira cómo se arregló.

      1. #1

        El DNS de casa iba cifrado… salvo el del servidor

        10-10-2026 · privacidad

        Lo que pasaba por el DNS de casa salía cifrado. Pero al revisar las conexiones del servidor seguía habiendo consultas DNS en claro hacia fuera.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        El hipervisor tenía resolutores públicos configurados y 16 de los 18 contenedores los heredaban: preguntaban fuera, por el 53, sin cifrar y sin caché.
        Solución
        Un playbook que apunta el hipervisor y los contenedores al DNS de casa, con un público solo de respaldo, actualizado en caliente sin reiniciar nada. Y el DNS, el primero en arrancar.
        Lección
        Comprobar el camino real del tráfico, no la configuración que se supone. El fallo estaba en el propio servidor, no en los equipos de casa.

      2. #2

        Se apaga el DNS de toda la casa

        13-09-2026 · migración

        La misma noche de la migración, la casa se quedó sin resolver nombres durante un rato.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Había dos contenedores con nombres parecidos: el de pruebas y el de producción. Apagué el que daba servicio pensando que era el viejo.
        Solución
        Encenderlo, comprobar resolución, bloqueos y redirección, volver a activar el arranque automático y renombrar los dos contenedores para que no se puedan confundir.
        Lección
        Los nombres son parte de la seguridad operativa: lo que se puede confundir, alguien lo confundirá. Yo incluido.

      3. #3

        ¿Forzar el DNS en el router?

        10-10-2026 · decisión

        Para que ningún equipo se saltara el DNS de casa, lo típico sería que el router redirigiera o bloqueara cualquier consulta al puerto 53 hacia fuera. No lo hice.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Tras un corte de luz, el servidor puede tardar más de una hora en arrancar. Con el 53 forzado, la casa se quedaría sin internet hasta entonces.
        Solución
        Decisión: no forzarlo. El DHCP reparte este DNS y quien lo necesite puede poner uno público a mano para seguir trabajando.
        Lección
        La seguridad que deja a todo el mundo sin servicio cuando falla una pieza no es una mejora. Se decide con el peor caso delante.

      Cómo se construyó

      1. Verano de 2026

        Pi-hole y Unbound

        • Bloqueo de publicidad para toda la casa y resolución recursiva propia.
        • Dos servicios que mantener y actualizar por separado.

      2. 13-09-2026

        Migración a Technitium

        • Instalado junto al anterior, con el paquete oficial verificado por su hash.
        • Mismas listas, mismos bloqueos y mismas zonas locales.
        • Cambio por redirección de puerto, sin tocar ningún cliente: 0 consultas perdidas.

      3. 10-10-2026

        Cifrado y arranque

        • Salida por DNS sobre HTTPS, comprobada mirando las conexiones.
        • El hipervisor y sus contenedores pasan a resolver aquí.
        • El DNS, el primero en arrancar tras un corte.

      Decisiones (y por qué)

      • Cómo migrar un servicio que usa todo el mundo

        En la misma dirección, con redirección de puerto

        Cambiar la IP del DNS obliga a tocar el DHCP y esperar a que cada equipo renueve. Redirigir el puerto dentro del mismo contenedor hace el cambio invisible y reversible en segundos.

      • Cómo sale fuera

        DNS sobre HTTPS

        Sin cifrar, cualquiera en el camino ve qué nombres se piden en casa. Con DoH, solo ve conexiones HTTPS a un resolutor.

      • La IP dinámica

        Un contenedor propio que actualiza Cloudflare

        Mi conexión no tiene IP fija. Un script pequeño en su propio contenedor es fácil de vigilar y no depende de servicios de terceros.

      Lo que aprendí

      • Un servicio que usa todo el mundo se cambia sin que nadie lo note, o no se cambia.
      • Mirar el tráfico real: el servidor seguía preguntando en claro mientras la casa ya iba cifrada.
      • Nombres que no se puedan confundir, sobre todo en lo que da servicio a todos.

      Lo siguiente

      • Servir también el DNS por IPv6 cuando esté resuelto el fallo que encontré al probarlo.
      • Llevar las listas y las zonas a código en el repositorio de infraestructura.

      ¿Hablamos?

      Puedo contar cualquiera de estas decisiones en detalle en una entrevista.

      Descargar CV Contactar ← Volver al rack

      Reconstrucción a partir de mi documentación: sin direcciones, zonas ni nombres internos.