DynIP – DNS dinâmico com suporte a RFC 2136, IPv6, DNSSEC e BYOD

 (dynip.dev)
1 pontos por GN⁺ 22 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • DynIP é um serviço de DNS dinâmico para homelabs, roteadores de borda e equipes de infraestrutura, oferecendo atualizações em 60 segundos e um plano gratuito
  • Suporta RFC 2136 TSIG, API REST e atualizações via UDP/53, com integração a FortiGate, OPNsense, OpenWRT e MikroTik
  • Suporta IPv6 junto com IPv4, atualizando registros A e AAAA em paralelo, cobrindo tanto dual stack quanto zonas somente IPv6
  • DNSSEC automatiza a geração de chaves de assinatura, a publicação na zona pai e a assinatura de registros, sendo necessário para emitir certificados Let’s Encrypt
  • Com BYOD, é possível conectar um domínio próprio e criar subdomínios dinâmicos, mas é preciso delegar para ns1.dynip.dev e ns2.dynip.dev

Visão geral do DynIP

  • DynIP é um serviço de DNS dinâmico para homelabs, roteadores de borda e equipes de infraestrutura, destacando atualizações em 60 segundos, plano gratuito, RFC 2136 TSIG, uso de domínio próprio e DNSSEC
  • Foi projetado para que, quando o roteador envie uma atualização, o hostname passe a resolver corretamente no mundo todo em cerca de 60 segundos
  • Oferece TTL de 60 segundos, propagação baseada em NOTIFY e servidores de nomes em múltiplas regiões
  • Disponibiliza cadastro gratuito e documentação

Padrões de DNS e integração com roteadores

  • Suporta RFC 2136 TSIG, podendo ser usado com FortiGate, OPNsense, OpenWRT e roteadores com suporte a DNS UPDATE
  • Usuários de MikroTik podem usar a integração nativa via HTTP API
  • Os métodos compatíveis incluem RFC 2136 TSIG, API REST e atualizações nativas por UDP/53
  • Na tela de snippets de configuração, é possível gerar e copiar blocos de configuração com base no tipo de dispositivo, IP de destino, domínio e chave TSIG
  • Enquanto uma nova zona estiver sendo propagada para os servidores de nomes, atualizações RFC 2136/TSIG do FortiGate precisam aguardar
  • Atualizações via HTTP API com cURL, PowerShell, Python e MikroTik funcionam imediatamente

IPv6 e DNSSEC

  • Suporta IPv6 junto com IPv4, permitindo atualizar registros A e AAAA em paralelo
  • Suporta tanto configurações dual stack quanto zonas somente IPv6
  • Para emitir certificados Let’s Encrypt, DNSSEC precisa estar ativado na zona correspondente
  • Ao ativar o DNSSEC, a geração das chaves de assinatura, a publicação na zona pai e a assinatura de todos os registros DNS são feitas automaticamente
  • A configuração do DNSSEC é um procedimento único; depois disso, a zona permanece assinada continuamente
  • O tempo estimado exibido é de 30 segundos

Início rápido e gerenciamento de zonas

  • O início rápido segue o fluxo de informar o nome do dispositivo, escolher o domínio base e clicar em Create Zone para criar a zona
  • No botão Snippets ao lado do novo domínio, é possível obter a configuração, selecionar o tipo de dispositivo e copiar o bloco gerado para a CLI do roteador
  • IPv4 e IPv6 são detectados e atualizados automaticamente com base nas conexões recebidas
  • A lista de zonas mostra domínio e ferramentas, IP atual, segredo TSIG, DNSSEC e status do certificado SSL
  • Em cada zona, é possível gerenciar estado de bloqueio, snippets, exclusão, notificações, horário de sincronização, ativação ou desativação do DNSSEC e download, renovação ou emissão de certificados SSL

Uso de domínio próprio

  • Com o recurso Custom Namespaces (BYOD), é possível conectar um domínio próprio ao DynIP e criar subdomínios dinâmicos dentro desse namespace
  • Para ativar o namespace, é necessário criar os dois registros NS no registrador do domínio
  • Delegação com apenas um NS é rejeitada
  • Os registros NS necessários são ns1.dynip.dev e ns2.dynip.dev
  • A validação da configuração é oferecida em um fluxo que confirma a ativação da delegação ou indica as ações necessárias no registrador

Sincronização rápida e automação

  • Quick Sync é um recurso que ajusta imediatamente a zona selecionada ao endereço IP externo atual do dispositivo
  • Exibe o IP de rede detectado e permite atualizar de uma vez as zonas escolhidas pelo usuário
  • Com um token de sessão, é possível registrar programaticamente uma nova zona enviando uma requisição POST ao endpoint /register
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
     -H "Authorization: Bearer {{ token }}"
  • O token de sessão expira ao fazer logout, então automações de longo prazo devem usar um token de API
  • API tokens são um recurso do plano Pro ou superior e podem ser usados em automações como scripts de monitoramento, pipelines de CI e integrações com MSP
  • Tokens de API não expiram ao fazer logout e podem ser limitados a escopo somente leitura ou acesso total, além de poderem ser revogados a qualquer momento
  • Um novo token de API é exibido apenas uma vez na criação, então ele deve ser guardado em um gerenciador de senhas ou cofre de segredos

Planos e segurança da conta

  • A tela de planos mostra o nível da assinatura, status, data de renovação ou fim de acesso, ciclo de cobrança, número de zonas em uso e quantidade máxima de domínios
  • Se o plano for rebaixado, apenas o número mais antigo de zonas permitido permanecerá ativo, e as demais zonas ficarão bloqueadas sem poder receber atualizações de IP
  • Em caso de falha no pagamento, é necessário atualizar a forma de pagamento para manter o acesso
  • A segurança da conta oferece suporte a 2FA por e-mail e TOTP, sendo que o TOTP substitui o 2FA por e-mail quando ativado
  • A configuração do TOTP consiste em escanear um QR code no Google Authenticator, Authy ou no aplicativo de 2FA de preferência e validar o código

Links relacionados

Leituras relacionadas

1 comentários

 
GN⁺ 22 시간 전
Comentários do Hacker News

  • Sou Daniel, engenheiro de redes na Suécia, e criei o DynIP porque senti que os serviços DDNS existentes ficaram presos às redes dos anos 2010
    Protocolos de atualização proprietários só via HTTP, suporte fraco a IPv6, ausência de DNSSEC e pouco suporte a equipamentos modernos eram problemas recorrentes, e o DynIP trata atualizações RFC 2136 / TSIG como caminho de primeira classe
    O DDNS genérico do FortiGate e o /tool dns-update do MikroTik funcionam sem cliente separado, e também há uma API HTTP para outros usos
    O servidor DNS autoritativo pode ser acessado por IPv6, há AAAA glue publicado na zona pai .dev, e as zonas dos clientes emitem A/AAAA, com suporte também a clientes somente IPv6
    Nas zonas selecionadas, o DNSSEC pode ser ativado com um único botão, e é possível trazer seu próprio domínio por meio de delegação de subdomínio
    A arquitetura usa um primary oculto que não recebe tráfego público, e dois secondary geograficamente distribuídos na Suécia e na Suíça validam o TSIG localmente antes de encaminhar ao primary
    Endereços RFC 1918 e CGNAT também são permitidos nos registros, para que frotas celulares em APN privada possam usar hostnames DNS públicos estáveis apontando para IPs internos
    Também existe um pequeno contêiner Docker chamado ghcr.io/33k-org/dynip-updater, e a stack é PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare e Paddle; está em operação em dynip.dev e há um plano gratuito

    • Não sou especialista em DDNS, mas talvez também valha a pena olhar o desec.io
      Ele oferece recursos como IPv6, DNSSEC e uso de domínio próprio, e além de ser um projeto open source também opera um serviço de hospedagem gratuito e estável
      Posso simplesmente não ter achado na documentação, mas lá existe suporte a delegação de prefixo IPv6, então quando o prefixo IPv6 atribuído pelo ISP ao roteador muda, você pode atualizar apenas o prefixo de rede de um domínio arbitrário
      Na Europa, esse prefixo não é fixo e muda sempre que o ISP reconecta, então é útil ter um recurso que preserve a parte do host e atualize automaticamente apenas a parte da rede
      Exemplo: /update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56
    • No Firefox Focus para Android, o site não funciona a menos que você desative a proteção contra rastreamento, que vem ativada por padrão
      Quando cliquei no link de confirmação por email, não apareceu nenhuma mensagem de confirmação nem indicação de status, então foi bem confuso
    • Ao clicar em “change password” no dashboard, um link de redefinição é enviado por email, mas a página de redefinição só aparece em uma sessão deslogada
      Se você estiver logado, o link redireciona para a página inicial do dashboard, então normalmente o usuário precisa fazer logout primeiro, já que recebe o email logo após clicar no botão de mudar senha
      Talvez fosse mais fluido incluir no email uma mensagem dizendo para fazer logout antes, ou fazer o link encerrar a sessão atual e então mostrar a página de redefinição
    • Fico curioso se vocês considerariam suporte a L402 para que agentes possam comprar o serviço
    • Fico preocupado se permitir endereços RFC 1918 e CGNAT nos registros pode criar problemas de segurança, como colocar o servidor privado de outra pessoa no próprio domínio e fazer algo do tipo ataque de XSS
      Tenho uma lembrança vaga de que isso era meio que um tabu de segurança

  • A proposta parece bem boa, mas não tenho tempo para testar agora
    Só que, se eu não tivesse lido a explicação neste comentário, acho que teria fechado a aba logo na landing page
    Desculpe ser tão direto, mas a página parece uma landing page genérica com cara de IA; não estou dizendo que seja de fato isso, mas como a explicação é boa, seria legal dar mais personalidade para se diferenciar
    E também é melhor não criar uma conta de projeto dedicada no Hacker News
    “Não use como nome de usuário o nome da empresa ou do projeto. Isso passa a impressão de que você está usando o HN para promoção e não participando como pessoa. Não precisa usar seu nome real, mas deve haver algum sinal de que há um ser humano aí, não uma marca. Se quiser mudar o nome de usuário, envie email para hn@ycombinator.com.”
    https://news.ycombinator.com/item?id=22336638
    Também vale consultar https://news.ycombinator.com/showhn.html

    • Boa observação, e não precisa pedir desculpas
      Neste momento, estou na fase de ter o que sei e o que não sei, esperanças e sonhos, e um bloco bem grande de conhecimento técnico; design não é meu forte, mas por enquanto acho que está aceitável
    • Este comentário longo aqui também parece texto gerado por LLM de forma bem óbvia
      Dá 100% no Pangram e, na verdade, é tão evidente que dá para perceber até sem essa ferramenta, então é meio desanimador ver que ainda há muita gente aqui que não consegue distinguir isso

  • É bom ver concorrência entrando nessa área
    Mas, se você quiser hospedar por conta própria sem se preocupar muito com confiabilidade ou facilidade de uso, o bind9 também suporta DNS UPDATE RFC 2136 e DNSSEC
    Na minha configuração, o roteador de casa não fala DNS UPDATE, então acabei criando eu mesmo um pequeno executável em Go que converte requisições HTTP

    • O BIND consegue fazer várias coisas, inclusive RFC 2136, e eu analisei várias opções antes de decidir pela arquitetura atual
      Criei alguns casos de teste no FortiGate, e o DynIP também começou como algo simples, praticamente um copiar e colar sobre o DNS interno, voltado especificamente para o FortiGate
      Há exemplos de código para uso interno em vários hosts Windows e Linux, e se você tiver equipamentos IoT no seu homelab, também existem exemplos para Arduino
      Criar um executável em Go também é um bom caminho, então vale acompanhar as atualizações em /docs

  • O suporte a RFC 2136 merece pontos extras, e funciona facilmente com external-dns
    Já faz alguns anos que uso Kubernetes on-premises com external-dns junto de um servidor BIND auto-hospedado com configuração mínima em um host público

    • A combinação external-dns + RFC 2136 é um ótimo ponto
      Já existe um guia para operação de fleet, e como o padrão de Kubernetes é uma extensão natural, acho que vale escrever um guia

  • Antigamente eu fazia meus próprios scripts de DDNS no OpenWrt para atualizar AWS Route 53 ou Cloudflare DNS, e isso já resolvia bem
    Depois que surgiu o Tailscale, parei de me preocupar com DDNS ou CGNAT

    • Tailscale, Netbird e WireGuard são todos excelentes, e hoje em dia é realmente uma ótima época por existirem ferramentas assim
      Escrevi um guia em https://dynip.dev/guides/tailscale explicando como e por que eles podem coexistir
      Os scripts de DDNS do OpenWrt são um pouco chatos por causa de chaves e segredos, mas estou bem satisfeito porque o recurso de snippet evita ter que adivinhar “como isso funciona?”
    • Hoje eu uso os dois
      Para serviços públicos uso DynIP, e para coisas que só eu preciso acessar uso Tailscale, o que reduziu bastante a superfície de ataque
      Felizmente não preciso me preocupar com CGNAT

  • Tentei me cadastrar, mas o e-mail de verificação não chega
    Logo após o cadastro também não havia nenhum indício parecido nos logs do servidor de e-mail, e mesmo pedindo reenvio várias vezes, até 6–7 horas depois ainda não havia nada na caixa de entrada

    • Acionei o reenvio para todos os e-mails ainda não verificados, então pode ter sido gerado um novo token de verificação
    • Se você me informar o endereço, eu verifico

  • Queria saber se é isso mesmo: o token de autenticação do plano gratuito expira depois de 24 horas
    Vi a claim exp do JWT e queria entender isso antes de gastar tempo com a migração
    O ponto principal é se o plano gratuito é sustentável

    • “long-lived token” significa um token da API de administração usado para criar, excluir e consultar zonas, ou para automação no estilo Terraform, e não a chave TSIG usada nas atualizações reais de DNS
      Todas as zonas recebem sua própria chave TSIG em todos os planos, e as atualizações reais são feitas por essa chave
      No plano gratuito, você gerencia as zonas pelo dashboard; nos planos pagos, ganha também tokens de API para gerenciamento programático
      Portanto, o token de autenticação é usado como bearer para a API, e a TSIG continua válida enquanto o domínio não for removido
      O plano gratuito permite 5 zonas, e cada uma tem sua própria chave TSIG sempre ativa, então, a menos que você esteja criando, atualizando e excluindo centenas de zonas, não há necessidade de pagar

  • Obrigado pelos muitos comentários e perguntas excelentes; vou continuar acompanhando a thread quando voltar, depois de passar algumas horas levando minha filha à aula de natação

  • Parece interessante, e eu uso DDNS para expor vários serviços do meu servidor caseiro a clientes externos
    Atualmente uso NO-IP DDNS, e o plano gratuito é bem generoso, mas me incomoda o fato de não oferecer suporte a algo como Let’s Encrypt
    Estou pensando em comprar um domínio no Cloudflare, mas queria entender exatamente o que o DynIP tem de diferente

    • Se a sua insatisfação atual com o NO-IP é não poder usar Let’s Encrypt, então você já encontrou uma funcionalidade que, para você, faz a diferença

  • Atualização no estilo dos anos 2000, somente via HTTP(S), também é boa
    Se houver curl/wget/fetch, funciona em qualquer lugar, e se quiser basta acrescentar um token
    Parece que o duckdns ainda oferece suporte a isso, e como não precisa de cliente separado, funciona praticamente em qualquer lugar

    • O modelo estilo dyndns com curl/wget/fetch também faz sentido, e basta olhar em /docs as outras funcionalidades especiais que podem ser feitas
      A ideia aqui não é incluir apenas curl/wget/fetch, mas lidar com uma base de funcionalidades mais ampla