DynIP – DNS dinámico compatible con RFC 2136, IPv6, DNSSEC y BYOD

 (dynip.dev)
1 puntos por GN⁺ 22 시간 전 | 1 comentarios | Compartir por WhatsApp
  • DynIP es un servicio de DNS dinámico para homelabs, routers de borde y equipos de infraestructura, con actualizaciones cada 60 segundos y un plan gratuito
  • Compatible con actualizaciones por RFC 2136 TSIG, API REST y UDP/53, e integrado con FortiGate, OPNsense, OpenWRT y MikroTik
  • Soporta IPv6 junto con IPv4 para actualizar registros A y AAAA en paralelo, tanto en entornos dual-stack como en zonas solo IPv6
  • DNSSEC automatiza la generación de claves de firma, la publicación en la zona padre y la firma de registros, y es necesario para emitir certificados de Let’s Encrypt
  • Con BYOD puedes conectar un dominio propio y crear subdominios dinámicos, pero requiere delegar en ns1.dynip.dev y ns2.dynip.dev

Resumen de DynIP

  • DynIP es un servicio de DNS dinámico para homelabs, routers de borde y equipos de infraestructura, que destaca por sus actualizaciones cada 60 segundos, plan gratuito, RFC 2136 TSIG, uso de dominio propio y DNSSEC
  • Está diseñado para que, cuando el router envía una actualización, el nombre de host se resuelva correctamente en todo el mundo en unos 60 segundos
  • Ofrece TTL de 60 segundos, propagación basada en NOTIFY y servidores de nombres multirregión
  • Ofrece registro gratuito y documentación

Estándares DNS e integración con routers

  • Soporta RFC 2136 TSIG, por lo que puede usarse con FortiGate, OPNsense, OpenWRT y routers con soporte para DNS UPDATE
  • Los usuarios de MikroTik pueden usar una integración nativa con HTTP API
  • Los métodos compatibles incluyen RFC 2136 TSIG, API REST y actualizaciones nativas por UDP/53
  • En la pantalla de snippets de configuración puedes generar y copiar un bloque de configuración según el tipo de dispositivo, la IP de destino, el dominio y la clave TSIG
  • Mientras una zona nueva se propaga a los servidores de nombres, las actualizaciones RFC 2136/TSIG de FortiGate deben esperar
  • Las actualizaciones por HTTP API como cURL, PowerShell, Python y MikroTik funcionan de inmediato

IPv6 y DNSSEC

  • Soporta IPv6 junto con IPv4 para actualizar registros A y AAAA en paralelo
  • Admite tanto configuraciones dual-stack como zonas solo IPv6
  • Para emitir certificados de Let’s Encrypt, DNSSEC debe estar habilitado en esa zona
  • Al activar DNSSEC, se automatizan la generación de claves de firma, la publicación en la zona padre y la firma de todos los registros DNS
  • La configuración de DNSSEC es un procedimiento de una sola vez, y después la zona permanece firmada
  • El tiempo estimado mostrado es de 30 segundos

Inicio rápido y administración de zonas

  • El inicio rápido consiste en ingresar el nombre del dispositivo, elegir el dominio base y hacer clic en Create Zone para crear la zona
  • Desde el botón Snippets junto al nuevo dominio puedes obtener la configuración, elegir el tipo de dispositivo y copiar el bloque generado al CLI del router
  • IPv4 e IPv6 se detectan y actualizan automáticamente según la conexión entrante
  • La lista de zonas muestra el dominio y herramientas, la IP actual, el TSIG Secret, DNSSEC y el estado del certificado SSL
  • En cada zona se puede gestionar el estado de bloqueo, snippets, eliminación, notificaciones, hora de sincronización, activación o desactivación de DNSSEC y la descarga, renovación o emisión de certificados SSL

Uso de dominio propio

  • La función Custom Namespaces (BYOD) permite conectar un dominio propio a DynIP y crear subdominios dinámicos dentro de ese namespace
  • Para activar el namespace, debes crear ambos registros NS en el registrador del dominio
  • No se acepta delegación con un solo NS
  • Los registros NS requeridos son ns1.dynip.dev y ns2.dynip.dev
  • La validación de la configuración se ofrece como un flujo para confirmar que la delegación está activa o revisar las acciones necesarias en el registrador

Sincronización rápida y automatización

  • Quick Sync es una función que ajusta de inmediato la zona seleccionada a la dirección IP externa actual del dispositivo
  • Muestra la IP de red detectada y permite actualizar de una vez las zonas elegidas por el usuario
  • Se pueden registrar nuevas zonas de forma programática enviando una solicitud POST al endpoint /register con un token de sesión
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
     -H "Authorization: Bearer {{ token }}"
  • Como el token de sesión expira al cerrar sesión, para automatización a largo plazo debe usarse un token de API
  • Los API tokens son una función disponible desde Pro en adelante y pueden usarse en automatizaciones como scripts de monitoreo, pipelines de CI e integraciones MSP
  • Los tokens de API no expiran al cerrar sesión, pueden limitarse a alcance de solo lectura o acceso total, y pueden revocarse en cualquier momento
  • Un nuevo token de API solo se muestra una vez al crearse, por lo que debe guardarse en un gestor de contraseñas o almacén de secretos

Planes y seguridad de la cuenta

  • La pantalla de planes muestra el nivel de suscripción, estado, fecha de renovación o fin de acceso, ciclo de facturación, cantidad de zonas en uso y número máximo de dominios
  • Si se baja de plan, solo las zonas más antiguas dentro del límite permitido permanecen activas, y el resto queda bloqueado sin poder recibir actualizaciones de IP
  • Si falla un pago, es necesario actualizar el método de pago para mantener el acceso
  • La seguridad de la cuenta soporta 2FA por correo electrónico y TOTP; cuando TOTP está activado, reemplaza al 2FA por correo
  • La configuración de TOTP consiste en escanear un código QR con Google Authenticator, Authy u otra app 2FA de preferencia y verificar el código

Enlaces relacionados

Lecturas relacionadas

1 comentarios

 
GN⁺ 22 시간 전
Comentarios de Hacker News

  • Soy Daniel, ingeniero de redes en Suecia, y creé DynIP porque sentía que los servicios DDNS existentes seguían atorados en redes al estilo de los años 2010
    Se repetían problemas como protocolos de actualización propietarios solo por HTTP, soporte débil para IPv6, ausencia de DNSSEC y poco soporte para equipos modernos, así que DynIP trata las actualizaciones RFC 2136 / TSIG como una vía de primera clase
    El DDNS genérico de FortiGate y /tool dns-update de MikroTik funcionan sin cliente adicional, y también ofrece una API HTTP para otros usos
    El servidor DNS autoritativo es accesible por IPv6, hay glue AAAA publicado en la zona padre .dev, y las zonas de clientes emiten A/AAAA, además de soportar clientes solo IPv6
    En las zonas seleccionadas se puede activar DNSSEC con un solo interruptor, y mediante delegación de subdominios puedes usar tu propio dominio
    La arquitectura consiste en un primary oculto que no recibe tráfico público y dos secondary distribuidos geográficamente en Suecia y Suiza, que validan TSIG localmente antes de reenviar al primary
    También se permiten direcciones RFC 1918 y CGNAT en los registros, para que flotas celulares con APN privado puedan usar nombres de host DNS públicos estables que apunten a IP internas
    También hay un pequeño contenedor Docker llamado ghcr.io/33k-org/dynip-updater, y el stack es PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare y Paddle; corre en dynip.dev y también tiene un nivel gratuito

    • No soy experto en DDNS, pero también vale la pena revisar desec.io, que ofrece funciones parecidas
      Ofrece funciones como IPv6, DNSSEC y uso de dominio propio, y además de ser un proyecto open source también opera un servicio de hosting gratuito estable
      Puede que no lo haya encontrado en la documentación, pero aquí sí hay soporte para IPv6 prefix delegation, así que cuando cambia el prefijo IPv6 que el ISP asignó al router, puedes actualizar solo el prefijo de red de un dominio arbitrario
      En Europa este prefijo no suele ser fijo y cambia cada vez que se reconecta el ISP, así que es útil una función que mantenga la parte del host y actualice automáticamente solo la parte de red
      Ejemplo: /update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56
    • En Firefox Focus para Android, el sitio no funciona a menos que desactives la protección contra rastreo, que viene activada por defecto
      Cuando hice clic en el enlace de verificación por correo no apareció ninguna confirmación ni indicador de estado, así que fue bastante confuso
    • Si haces clic en “change password” en el dashboard, llega por correo un enlace de restablecimiento, pero la página de restablecimiento solo se muestra en una sesión cerrada
      Si estás con sesión iniciada, el enlace redirige al inicio del dashboard, así que como normalmente el usuario recibe el correo justo después de pulsar el botón para cambiar contraseña, primero tiene que cerrar sesión
      Sería más fluido si el correo dijera “primero cierra sesión”, o si el enlace cerrara la sesión actual antes de mostrar la página de restablecimiento
    • Me pregunto si podrían considerar soporte para L402 para que los agentes puedan comprar el servicio
    • Me preocupa si permitir direcciones RFC 1918 y CGNAT en registros podría generar problemas de seguridad, como meter el private server de otra persona en tu dominio para hacer ataques tipo XSS
      Recuerdo vagamente que esto era algo prohibido desde el punto de vista de seguridad

  • La propuesta se ve bastante bien, pero ahora mismo no tengo tiempo de probarla
    Dicho eso, si no hubiera leído la explicación en los comentarios de aquí, creo que habría cerrado la pestaña apenas al ver la landing page
    Perdón por ser tan directo, pero la página parece la típica landing page genérica con vibra de IA; no digo que realmente lo sea, pero como la explicación es buena, estaría bien diferenciarla más dándole personalidad
    Además, es mejor no crear una cuenta de Hacker News dedicada al proyecto
    “No uses como nombre de usuario el nombre de una empresa o proyecto. Da la impresión de que usas HN para promocionarte y de que no participas como persona. No necesitas usar tu nombre real, pero sí dar la señal de que aquí te ven como un ser humano y no como una marca. Si quieres cambiar tu nombre de usuario, escribe a hn@ycombinator.com.”
    https://news.ycombinator.com/item?id=22336638
    También puedes revisar https://news.ycombinator.com/showhn.html

    • Es un buen punto y no hace falta que te disculpes
      En este momento estoy en la etapa de tener cosas que sé y cosas que no sé, esperanzas y sueños, y un bloque bastante grande de conocimiento técnico; no soy fuerte en diseño, pero por ahora me parece aceptable
    • Este comentario largo de aquí también parece texto producido en masa por un LLM de forma descarada
      Según Pangram da 100%, y la verdad ni siquiera hace falta una herramienta así para darse cuenta; es deprimente que incluso aquí no sean pocos los que no logran distinguirlo

  • Me alegra ver competencia entrando en esta área
    Pero si quieres hacer self-hosting sin preocuparte demasiado por estabilidad o facilidad de uso, bind9 también soporta RFC 2136 DNS UPDATE y DNSSEC
    En mi configuración, el router de mi casa no puede hablar DNS UPDATE, así que también hice yo mismo un pequeño ejecutable en Go que convierte solicitudes HTTP

    • BIND puede hacer varias cosas, incluida RFC 2136, y revisé varias opciones antes de decidirme por la arquitectura actual
      Hice algunos casos de prueba en FortiGate, y al principio DynIP empezó como una copia y pega simple encima del DNS interno, pensado solo para FortiGate
      Hay ejemplos de código que pueden usarse internamente en varios hosts de Windows o Linux, y si tienes equipos IoT en tu homelab, también hay ejemplos para Arduino
      Hacer un ejecutable en Go también es un muy buen camino, así que puedes seguir las actualizaciones bajo /docs

  • Que admita RFC 2136 merece puntos extra, y funciona fácilmente con external-dns
    Llevo años usando Kubernetes on-premise con external-dns, junto con un servidor BIND autoalojado en una configuración mínima de host público

    • La combinación external-dns + RFC 2136 es un muy buen punto
      Ya existe una guía de operación de flota, y como el patrón de Kubernetes es una extensión natural, parece que habría que escribir una guía

  • Antes actualizaba AWS Route 53 o Cloudflare DNS creando yo mismo scripts DDNS para OpenWrt, y con eso se resolvía bastante bien
    Después de que apareció Tailscale, dejé de preocuparme por DDNS o CGNAT

    • Tailscale, Netbird y WireGuard son excelentes, y de verdad esta es una gran época porque ahora existen herramientas así
      Dejé escrita una guía en https://dynip.dev/guides/tailscale explicando cómo y por qué pueden coexistir entre sí
      Los scripts DDNS de OpenWrt son algo engorrosos por las claves y secretos, pero estoy bastante satisfecho con la función de snippets porque evita tener que adivinar “¿cómo funciona esto?”
    • Ahora uso ambos
      Para servicios públicos uso DynIP, y para lo que solo necesito acceder yo uso Tailscale, así que la superficie de ataque se redujo mucho
      Por suerte, no hace falta preocuparse por CGNAT

  • Intenté registrarme, pero no llega el correo de verificación
    Justo después del registro tampoco había nada parecido en los logs del servidor de correo, y aunque pedí reenvío varias veces, hasta 6 o 7 horas después no había nada en la bandeja de entrada

    • Activé el reenvío para todos los correos no verificados, así que puede que se haya generado un nuevo token de verificación
    • Si me dices la dirección, lo reviso

  • Me gustaría saber si es correcto que el token de autenticación del plan gratuito vence después de 24 horas
    Vi el claim exp del JWT, y quiero saber este punto antes de invertir tiempo en la migración
    Lo clave es si el plan gratuito es sostenible

    • “long-lived token” no se refiere a una clave TSIG para actualizaciones DNS reales, sino a un token de API de administración que se usa para crear, eliminar o consultar zonas, o para automatización tipo Terraform
      Todas las zonas reciben su propia clave TSIG en todos los planes, y las actualizaciones reales las maneja esa clave
      En el plan gratuito se administran las zonas desde el dashboard, y en los planes de pago además se ofrecen tokens de API para administración programática
      Así que el token de autenticación se usa como bearer para la API, y la TSIG sigue siendo válida mientras no se elimine el dominio
      El plan gratuito permite 5 zonas y cada una tiene una clave TSIG individual siempre activa, así que no hace falta pagar a menos que vayas a crear, actualizar y borrar cientos de zonas

  • Gracias por los excelentes comentarios y preguntas; estuve unas horas llevando a mi hija a su clase de natación y ya volví, así que seguiré viendo el hilo

    • La natación también está bien, y la dinámica de fluidos también importa
      Me pregunto si también consideraste algo como https://github.com/hickory-dns/hickory-dns
      Aunque claro, tampoco hace falta hacer todo en Rust

  • Se ve interesante, y uso DDNS para ofrecer varios servicios desde mi servidor casero a clientes externos
    Ahora uso NO-IP DDNS y su plan gratuito es bastante generoso, pero me molesta que no soporte algo como Let’s Encrypt
    Estoy pensando si comprar un dominio en Cloudflare, pero me da curiosidad qué diferencia concretamente a DynIP

    • Si lo que te molesta de NO-IP ahora mismo es no poder usar Let’s Encrypt, entonces ya encontraste una función que para ti marca una diferencia clara

  • Las actualizaciones solo por HTTP(S) al estilo de los 2000 también están bien
    Con solo curl/wget/fetch, funciona en cualquier lado, y si quieres basta con agregar un token
    Parece que duckdns todavía soporta este método, y como no requiere un cliente aparte, funciona casi en cualquier lugar

    • Lo de curl/wget/fetch estilo dyndns también es cierto, y en /docs puedes revisar las demás funciones especiales que se pueden hacer
      La idea aquí no es incluir solo curl/wget/fetch, sino apuntar a una base de funcionalidades más amplia