Por que aprender DNS ainda é tão difícil?

 (jvns.ca)
3 pontos por GN⁺ 2023-07-29 | 1 comentários | Compartilhar no WhatsApp
  • O DNS é usado há mais de 35 anos, desde os anos 1980, e sua estrutura é estável, mas muitos programadores ainda levam muito tempo até conseguirem depurar com confiança problemas básicos
  • A dificuldade não está tanto na complexidade do próprio DNS, mas na quantidade de componentes invisíveis, como cache do resolver, bibliotecas DNS locais e a conversa com servidores de nomes autoritativos
  • O dig é poderoso, mas a estrutura da saída e a terminologia não são familiares, e recursos como +norecurse, embora úteis, não têm uma interpretação de resultado intuitiva
  • Armadilhas comuns como negative caching, o histórico de falta de suporte a DNS via TCP no musl, resolvers que ignoram TTL, cache permanente no nginx e o ndots do Kubernetes são difíceis de aprender até que alguém as explique
  • Para quem lida com DNS raramente, um guia rápido pode ajudar, e problemas em que experimentar parece arriscado podem ser amenizados com um ambiente seguro de testes como o Mess With DNS

DNS difícil apesar de ser uma tecnologia antiga

  • O DNS é usado há mais de 35 anos, desde a época da RFC 1034, está presente em todos os sites da internet e, em muitos aspectos, funciona de forma parecida com 30 anos atrás
  • Mesmo assim, pode levar muito tempo para depurar problemas básicos como “o domínio foi configurado corretamente, mas não resolve” ou “o resultado de DNS no dig é diferente do navegador”
  • Quem tem dificuldade com DNS costuma travar nestes pontos
    • não se sente à vontade nem com mudanças simples de DNS em um site
    • confunde o fato de que registros DNS não são enviados, e sim consultados (pull)
    • mesmo entendendo os conceitos básicos, se confunde com detalhes de funcionamento como negative caching e as diferenças entre consultas DNS do dig e do navegador

Resolvers e servidores de nomes invisíveis

  • O fluxo básico ao enviar uma requisição DNS do computador parece simples
    • o computador faz uma requisição a um servidor chamado resolver
    • o resolver verifica o cache e, se necessário, consulta novamente o authoritative nameserver
  • Na depuração real, vários fatores importantes não aparecem de forma explícita
    • é difícil saber o que está dentro do cache do resolver
    • não é claro qual biblioteca DNS local está processando a requisição
      • pode ser a libc getaddrinfo, glibc, musl, implementação da Apple, código DNS do próprio navegador ou outra implementação personalizada
      • cada implementação difere um pouco em configuração, forma de cache e suporte a recursos
      • o DNS do musl não suportava TCP até o início de 2023
    • a conversa entre o resolver e o authoritative nameserver não é visível
      • se fosse possível acompanhar para qual authoritative nameserver a consulta foi enviada e qual foi a resposta, muitos problemas de DNS seriam mais fáceis de entender

Uma abordagem para revelar os sistemas ocultos

  • Só de mostrar quais são os componentes escondidos, já se ajuda muito no aprendizado
    • se você não souber que um mesmo computador pode usar várias bibliotecas DNS dependendo da situação, pode ficar confuso por muito tempo
  • O Mess With DNS tenta fazer experimentos em estilo fishbowl, mostrando partes que normalmente ficam escondidas
    • ele permite ver parte da conversa entre o resolver e o authoritative nameserver
  • Também existe a abordagem de incluir informações de depuração na resposta DNS
    • já existe um recurso chamado Extended DNS Errors, ou EDE
    • as ferramentas estão adicionando suporte a EDE aos poucos

As pistas dadas por Extended DNS Errors

  • Extended DNS Errors é uma nova forma de o servidor DNS fornecer informações extras de depuração na resposta
  • Ao consultar o domínio inexistente xjwudh.com com dig @8.8.8.8 xjwudh.com, pode aparecer um erro adicional como este
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
  • Esse exemplo parece estar relacionado a DNSSEC, e o importante é que a resposta traz junto uma mensagem extra de depuração
  • Para ver esse exemplo, foi necessário usar uma versão mais recente do dig

dig: poderoso, mas difícil de ler

  • O dig é útil para verificar o estado interno do DNS
  • Com dig +norecurse, é possível ver quais registros um determinado resolver DNS tem em cache
    • o 8.8.8.8 aparentemente retorna SERVFAIL se a resposta não estiver em cache
    • google.com está em cache, então retorna NOERROR e um registro A
    • homestarrunner.com não está em cache e retorna SERVFAIL, mas isso não significa que o registro DNS não exista
  • A saída do dig é difícil de ler se você não estiver acostumado
    • títulos como ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION: e ANSWER SECTION: são pouco familiares
    • as quebras de linha e os espaços entre seções não parecem consistentes
    • em MSG SIZE rcvd: 47, é difícil saber se existem outros campos além de rcvd
    • é preciso saber que, embora diga haver 1 registro na seção ADDITIONAL, na prática o OPT PSEUDOSECTION cumpre esse papel
  • A saída do dig parece menos um formato deliberadamente projetado desde o começo e mais um script que cresceu organicamente ao longo do tempo

Como tornar ferramentas de DNS mais legíveis

  • Uma documentação que explique a própria saída do dig já ajuda bastante
    • how to use dig explica a estrutura da saída do dig e como configurar uma saída básica mais curta
  • Também é possível criar ferramentas mais amigáveis
    • há alternativas como dog, doggo e DNS lookup tool
    • ainda assim, quando você precisa de recursos avançados como +norecurse, pode ser melhor resolver tudo com o próprio dig
    • substituir toda a ampla gama de recursos do dig é um trabalho grande
  • Outra possibilidade seria adicionar algo como uma opção +human ao dig, mostrando as mesmas informações de forma mais estruturada
    • cabeçalho, consulta, resposta, seções adicionais, tempo, servidor, protocolo e tamanho da resposta poderiam ser separados com clareza
    • a ideia não é reduzir a quantidade de informação, mas apresentar a mesma informação de forma mais legível
  • As versões recentes do dig têm formato de saída +yaml
    • ele pode parecer mais claro, mas pode ser tão verboso que até uma resposta DNS simples não cabe inteira na tela

Armadilhas de DNS frequentes, mas difíceis de aprender

  • No DNS, existem armadilhas relativamente comuns, mas difíceis de perceber até que alguém as explique

  • negative caching

    • se você visitar um domínio que ainda não tem um registro DNS, o estado de “não existe” desse registro pode ficar em cache
    • se isso ficar em cache por algumas horas, pode ser muito incômodo

  • diferenças de implementação do getaddrinfo

  • resolvers que ignoram TTL

    • mesmo que você configure o TTL de um registro DNS para 5 minutos, alguns resolvers podem ignorar isso e manter o cache por muito mais tempo, como 24 horas

  • problemas de configuração do nginx

    • se o nginx for configurado incorretamente, ele pode manter registros DNS em cache para sempre

  • ndots do Kubernetes

    • o ndots pode deixar o DNS do Kubernetes mais lento

Como compartilhar e documentar armadilhas

  • É difícil adquirir conhecimento sobre armadilhas estranhas, e é ineficiente que as pessoas precisem redescobrir os mesmos problemas repetidamente
  • Ao explicar um tema, ajuda muito apontar também as armadilhas mais comuns
    • em um exemplo fora de DNS, a introdução ao Flexbox de Josh Comeau explica a minimum size gotcha
  • Também é útil quando a comunidade reúne armadilhas comuns em um só lugar
    • no Bash, o shellcheck é extremamente útil como coleção de armadilhas de bash
  • Documentar armadilhas de DNS também é difícil porque os problemas encontrados variam de acordo com o usuário
    • quem configura o DNS de um domínio pessoal uma vez a cada 3 anos e quem opera o DNS de um domínio com muito tráfego enfrentam armadilhas diferentes

Uso raro e dificuldade para experimentar

  • Muitas pessoas lidam com DNS muito raramente
    • se você mexe com DNS só uma vez a cada 3 anos, é natural que seja difícil aprender
    • um guia rápido para coisas como “procedimento para trocar nameservers” pode ajudar
  • O DNS também é uma tecnologia em que as pessoas têm receio de experimentar, porque podem quebrar o próprio domínio
    • o Mess With DNS foi criado para reduzir esse medo de experimentar

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-29
Opiniões do Hacker News

  • Não concordo com este texto. DNS é algo que pouca gente dedica tempo para aprender; não acho que seja, de fato, difícil de aprender
    O ponto bom do DNS é que o sistema informa seu próprio estado interno em resposta às consultas. É fácil examinar um servidor DNS para uma zona conhecida e entender como ele funciona, e ferramentas gratuitas como dig também estão amplamente disponíveis
    Sempre me surpreendeu que as pessoas com quem trabalhei ao longo da carreira se lembrem mais do meu conhecimento de DNS, porque não acho que eu saiba algo misterioso ou especial. DNS é muito bem padronizado, as implementações comuns de servidores e clientes seguem o padrão de forma rigorosa, e também é fácil observá-lo com ferramentas gratuitas. Exige esforço e tempo, mas não é realmente difícil

    • Como autora do texto, queria comentar alguns pontos sobre a visão de que DNS não é realmente difícil. Levei vários anos até me sentir totalmente confortável para depurar problemas de DNS, e escrevi este texto para explicar por que foi difícil para mim
      Antes, eu achava que “não, na verdade é fácil!” era um incentivo diante de alguém dizer “é difícil de aprender”. Gosto de DNS e também acho que ele é surpreendentemente simples em vários aspectos. Por exemplo, em https://implement-dns.wizardzines.com eu mostro como implementar do zero um resolvedor DNS de brinquedo com código Python simples
      Mas, com o tempo, aprendi que “não, é fácil de aprender!” muitas vezes é recebido menos como um “você consegue!” e mais como “não é difícil, você é que é burro”. Quando é um tema que me confundiu por anos, ouvir “na verdade é fácil” não ajuda muito
      Por isso, hoje não falo mais assim; em vez disso, tento dedicar bastante esforço a entender por que as pessoas acham certas coisas difíceis e a reduzir essas barreiras
    • Acho que é difícil de aprender quando se olha para as ferramentas para aprender DNS
      O BIND cumpre muito bem seu papel, mas os arquivos de configuração não são bons, o manual é longo e rígido e às vezes desnecessariamente complexo. dig é poderoso, mas abrevia tudo como se ainda estivéssemos na época dos terminais de 80 colunas. Ao depurar problemas de DNS, já houve casos em que o Wireshark foi uma ferramenta melhor do que dig
      Acho que, se as pessoas usassem PowerDNS ou outro servidor DNS moderno, seria muito mais fácil configurar um servidor DNS funcional. Não conheço um bom cliente DNS moderno, então acabei me acostumando com dig. Como alguém que usa a flag --color do comando ip, eu gostaria que ferramentas como dig tivessem uma saída mais moderna. As flags de linha de comando eu coloco em aliases; só queria que adicionassem os recursos
      Falando sério, MSG SIZE rcvd: 71 não precisava ser abreviado. flags: qr rd ra também poderia ter sido escrito por extenso. Também não sei o que o ponto e vírgula no início das linhas quer comunicar; ele só causa mais confusão
      Não é estranho que as pessoas fiquem confusas ao aprender DNS com os materiais disponíveis
    • Você disse “não concordo com este texto”, mas parece que quase não respondeu aos argumentos do texto e discordou apenas do título. Além disso, parece misturar DNS é difícil com DNS é difícil de aprender
      Se “só exige um pouco de esforço e tempo”, quanto esforço e quanto tempo são necessários? Várias pessoas nesta thread dizem que aprenderam implementando um servidor, ou que levaram meses para entender, e depois repetem que “uma vez que você entende, é bem fácil”. Então não podemos concordar que, para algo tão universal e conceitualmente simples, ele é de fato difícil de aprender?
    • Ao ler o texto, dá para ver por que é difícil de aprender. O conceito é fácil, mas, ao ensinar o conceito, não se incluem todos os detalhes da internet moderna
      Por exemplo, quais são as regras pelas quais um navegador armazena em cache e expira entradas de DNS? Essas regras são consistentes entre navegadores?
    • Vejo DNS como uma daquelas tecnologias das quais você pode ir pegando fragmentos aqui e ali ao longo da carreira. Se muita gente tivesse sido obrigada a lidar com ela de frente, ela pareceria menos complexa do que parece na prática, mas na indústria essas coisas acabam ganhando uma certa aura de mistério

  • Acho que o texto acertou no ponto central. DNS em si não é difícil, mas aprender DNS no mundo real é difícil. Isso porque muita coisa no meio, entre fazer uma consulta e obter o resultado pretendido e esperado, fica escondida
    Antigamente, a forma básica de conexão à internet era uma interface, um gateway e um provedor de servidor DNS. Hoje, às vezes estamos conectados simultaneamente a várias WANs, como LTE e WiFi, e fica difícil para o usuário saber qual caminho de resolução foi realmente usado. Não fica claro se foi o navegador, a interface padrão da biblioteca C do sistema, algum resolvedor local ou recursivo intermediário, se há cache local ou se opções especiais são acrescentadas por padrão
    Mesmo quando tudo funciona, não dá para acreditar cegamente que a consulta e a resposta de uma aplicação usaram o mesmo caminho de outra aplicação. Três navegadores podem usar métodos diferentes, o sistema operacional pode se comportar de outro jeito, e o mDNS ainda pode acrescentar uma quinta opção

  • Há uma piada de que, na ciência da computação, existem apenas três problemas difíceis: invalidação de cache e dar nomes
    E DNS é um sistema de cache para nomes de coisas
    https://reddit.com/comments/15c2ul2/comment/jtty9dy

    • Para ser justo, DNS é um dos casos em que dar nomes foi feito direito
      É gerenciado globalmente (IANA), hierárquico, federado e fácil de modificar

  • DNS é o tipo de tecnologia em que há uma discrepância entre o quanto parece fácil e a dificuldade que aparece na prática
    Usamos DNS todos os dias, e ele parece muito simples. A linguagem cotidiana de DNS é nome de domínio, consulta e endereço IP. Essa linguagem fica exposta diretamente no navegador, e, a partir dessa exposição, criamos um modelo mental de como ele funciona
    Mas, por dentro, há uma linguagem completamente diferente: zonas, resolvedores, autoridade delegada, aquele ponto estranho depois do domínio de topo

    • Esse ponto estranho é chamado de raiz. Sem o ponto, o nome não está completo; com o ponto, o nome fica totalmente definido. Ou seja, contexto é tudo. Sem o ponto, o resolvedor pode anexar repetidamente o próprio domínio, ou partes dele
      Por exemplo, nós dois sabemos o que host.example.co.uk significa, mas, sem o ponto no final, o resolvedor pode tentar consultar host.example.co.uk.example.co.uk
      Nas configurações padrão do Windows, nesses casos ele pode tentar host.example.co.uk.example.co, host.example.co.uk.example, de novo host.example.co.uk.example, e então host.example.co.uk., e acabar obtendo um resultado. Dito isso, nunca vi o Windows realmente fazer a primeira tentativa, e esse comportamento parece ter sido projetado para lidar com ambientes de grandes empresas com Active Directory federado e monstruoso
      Hoje em dia, os navegadores têm grande chance de ir sorrateiramente para servidores de DNS over HTTPS (DoH) sem consentimento do usuário e se misturar com todo tipo de contraparte suspeita. Consultas DNS são dados básicos, então os ISPs gostavam de ver para onde o usuário estava indo. Fornecedores de sistema operacional, naturalmente, também podem enviar “telemetria”. O Google não é dono do desktop, mas é dono do navegador, então é bom para eles fazer o usuário usar servidores DNS “seguros” em vez do DNS configurado por ele. Por causa dessas artimanhas, solucionar problemas de TI ficou muito mais empolgante do que antes
      Não é preciso se preocupar demais com o ponto no final. Afinal, quase certamente você não está usando o servidor DNS que imagina estar usando. Entendo por que DoH foi criado, e alguns usuários comuns têm motivos para usá-lo. Por exemplo, quando alguém que não é profissional de TI usa um hotspot Wi-Fi malicioso, o navegador consultar DNS de volta à base, de forma segura, oferece alguma proteção. Mas se fornecedores de navegador podem atropelar as escolhas de segurança de endpoint do usuário é outra questão
      DNS é muito mais complexo do que simplesmente consultar endereços. Hoje é uma questão de dinheiro e, na verdade, sempre foi assim desde mais ou menos 2000. Agora há muitas megacorporações muito teimosas que querem decidir quem vai lucrar por meio dos usuários
    • Acho que a parte difícil é a distribuição. Acima do nível atômico dos nós individuais acontece uma quantidade enorme de magia negra, e é isso que cria a maior parte da complexidade e da opacidade
      DNS em si é fácil. Distribuir informação sem ficar preso a uma organização é que é realmente complicado

  • Alguns anos atrás, percebi que eu entendia DNS só em pedaços. Eu conhecia dig(1), BIND e o conceito em nível CS101 de como a resolução DNS recursiva funciona, mas me faltava o conhecimento prático necessário para projetar e implementar um sistema não trivial, ou para depurar um sistema que não funcionava
    Então li “DNS and BIND” praticamente do começo ao fim, e também configurei servidores BIND reais para alguns sites pessoais menos importantes. Não foi difícil, mas exigiu um bom investimento de tempo. BIND não é a resposta certa para muitos casos de uso, mas foi muito valioso porque muitos conceitos e termos de DNS ainda vêm do BIND
    Acho que livros são subestimados para aprender esse tipo de coisa. O material encontrado na web geralmente é teoria de alto nível, como diagramas de blocos de consultas recursivas; material orientado a tarefas, como fazer uma consulta recursiva com dig; ou material de baixo nível, como ler o código-fonte para entender a política de novas tentativas do cliente DNS local. Para entender cada peça, como elas se encaixam, o que estão tentando alcançar, e também detalhes de implementação como onde ficam os caches, há pouco substituto para a abordagem abrangente que se encontra com frequência em livros. Na web isso até existe, mas é raro

  • Todo profissional de TI deveria ter conhecimento prático de depuração de problemas de DNS
    DNS historicamente foi um vetor para vulnerabilidades de segurança importantes, e provavelmente continuará sendo. Essas vulnerabilidades abrem caminhos de ataque para quase todos os outros protocolos, como SMTP. Até o sistema de autoridades certificadoras usado em HTTPS depende muito de um protocolo que, em essência, não é seguro. Se um banco comprasse um certificado DV em vez de OV, você perceberia? Provavelmente não
    Então talvez não seja tão ruim que DNS pareça difícil de aprender para quem não tem interesse suficiente. Ainda hoje vejo pessoas criando funcionalidades relacionadas a DNS sem dedicar tempo para entender direito a história de coisas como randomização de portas, envenenamento de cache e AXFR

    • Qualquer coisa que faça broadcast ou alegue decisões de roteamento em qualquer camada da rede parece mais simples do que realmente é, mas potencialmente perigosa

  • Fazendo uma divulgação descarada de um side project: o texto dizia que seria bom se a resolução DNS tivesse um modo de “debug”, e a UI web do ComfyDNS tem isso :3
    https://comfydns.com/
    A imagem no topo com TRACE google.com A IN escrito é essa funcionalidade
    ComfyDNS também é um projeto para coçar uma coceira pessoal. Eu estava cansado de editar arquivos de zona do bind9 na mão, e também tinha curiosidade sobre como o DNS funcionava. Eu conhecia a superfície, mas não os detalhes, então implementei as RFCs “do zero”. Usei netty, mas não usei biblioteca de DNS. Foi bem divertido
    Peço desculpas se o site não aguentar o tráfego e cair. É uma aplicação Rails rodando no free tier da Oracle Cloud

  • A piada que eu sempre ouvia era que DNS junta os dois problemas mais difíceis da ciência da computação: dar nomes e invalidação de cache

    • DNS tem um contador de validade em segundos, e tudo bem ser bastante flexível ao contar esses segundos
      Não é o tipo difícil de invalidação de cache. Na verdade, quase nunca é preciso “invalidar”
      Do lado do servidor, também é totalmente aceitável enviar uma mistura da versão antiga e da nova por um tempo
    • Não é piada, está certo

  • Parece mais um texto desses. Nos anos 1990, a internet era menor e os computadores eram muito mais lentos e menos potentes, mas a gente aprendia com muita facilidade
    Naquela época, para um ISP, coisas como DNS, LDAP, SMTP, IMAP eram o básico do básico, e as pessoas de fato liam documentos oficiais como RFCs. Se você queria operar um servidor na internet, precisava aprender, e dava para aprender investindo um pouco de tempo — ou seja, usando o tempo remunerado no trabalho
    A geração atual de desenvolvedores e DevOps não tem paciência nem iniciativa, espera tudo mastigado e copia e cola qualquer coisa do StackOverflow e de blogs de baixo valor. Em vez de aprender os fundamentos sobre os quais a internet foi construída, pega a ferramenta wrapper da moda da semana, segue instruções ruins de algum blog e, quando tudo desaba e a empresa perde muito dinheiro, acha injusto. Isso acontece porque não dedicou tempo para aprender o básico de como as coisas realmente funcionam na internet
    Tenho visto isso acontecer repetidamente. Na verdade, não é tão difícil. É só fazer a lição de casa

  • Não é difícil. DNS é uma das poucas tecnologias que não mudaram muito, e seu funcionamento também é bastante intuitivo
    dig pode ser um pouco confuso. Tem mais recursos que o antigo nslookup, mas é menos intuitivo. Aliás, nslookup ainda funciona muito bem
    Acho que um dos motivos pelos quais as pessoas mais jovens do setor se confundem com DNS e protocolos centrais é que hoje muitas coisas “simplesmente funcionam”
    Por exemplo, os roteadores WiFi de hoje “simplesmente funcionam” assim que saem da caixa. No começo dos anos 2000, para configurar algo assim, era preciso um engenheiro de redes que entendesse DNS, IP, Ethernet, RFC1918, protocolos reais de roteamento e muitas outras coisas, e provavelmente soubesse bem por que estava configurando daquele jeito
    Se você acha DNS do ponto de vista do cliente confuso, experimente configurar o BIND ;-)
    /resmungo de um velho barbudo

    • Aos 14 anos, administrei de forma improvisada o ambiente Active Directory de um restaurante, incluindo e-mail, web e CIFS, sem entender DNS nem DHCP
      Eu deveria ter feito o servidor DHCP do WRT54G distribuir o IP fixo do controlador de domínio como servidor DNS para que a resolução de nomes funcionasse corretamente, mas simplesmente fiz tudo funcionar com endereços IP e entradas no arquivo hosts. Também configurei o registro MX do domínio para o IP WAN do roteador e não havia registro PTR. Olhando para trás, foi um milagre a entrega de e-mails ter funcionado tão bem
      Alguns anos depois, entendi como o DNS realmente funciona e, no começo dos meus 20 anos, herdei uma intranet corporativa que usava BIND como servidor de nomes para todas as zonas de domínios corporativos externos. Ao migrar essa configuração para um VPS para aumentar a confiabilidade, aprendi muito sobre transferências de zona, SOA etc. Sou grato por essa experiência, mas hoje quase tudo é tratado por terceiros, então virou uma atividade de baixo valor. Para o bem ou para o mal, “TI” não é valorizada da mesma forma que “engenharia de software”
    • É verdade que o funcionamento é relativamente intuitivo, mas isso só vale quando se ignoram todos os tipos de comportamentos estranhos possíveis, como servidores que ignoram o TTL
      Não consigo esquecer quando o Firefox lançou uma atualização que ativava DNS-over-HTTPS por padrão. Nós distribuíamos servidores DNS internos para as estações de trabalho via DHCP e, de repente, começaram a chover reclamações do tipo “meu e-mail sumiu! está tudo quebrado!”. O webmail interno e os servidores web da intranet pareciam simplesmente ter desaparecido
      Demorou mais do que deveria para entender o que estava acontecendo. Em parte por causa do pensamento “é DNS, por que quebraria de repente?”. Mas ficou bem claro que a Mozilla não previu esse problema facilmente antecipável
    • O que foi mencionado aqui é apenas uma pequena parte do DNS
      Por exemplo, ao consultar thing.behind.cdn.it, eu recebo uma resposta, enquanto outra pessoa recebe outra resposta para o mesmo nome. Isso por si só é bem óbvio, mas a coisa complica quando alguém pergunta, de forma razoável: “vocês podem abrir uma exceção no firewall para thing.behind.cdn.it?”
      Alguns servidores encaminham solicitações, alguns delegam, alguns fazem a consulta em nome de você e outros não. Também existe a mágica dos domínios de busca no cliente, e não é garantido que o cliente ou a biblioteca resolvedora interna respeite o TTL
      Há inúmeros tipos de registro, e às vezes o servidor também manda reconectar por TCP em vez de UDP
      Por isso, DNS é bastante complexo. Como funciona muito bem e a maior parte das partes difíceis é abstraída em coisas que “em geral simplesmente funcionam”, existe a ilusão de que é simples
    • Sobre conhecer protocolos antigos, nas últimas semanas li Networking for System Administrators e criei e revisei muitas anotações em cartões do Anki
      É surpreendente como ganhei muito mais confiança para entender redes em alto nível, incluindo DNS e até coisas por baixo dele, como ethtool e frames Ethernet
      Gosto de entender as coisas desde a base; escolhi engenharia elétrica em vez de ciência da computação na universidade, então talvez isso nem seja tão surpreendente
    • Sim, configurar BIND é difícil. Unbound/nsd é muito mais fácil de lidar. Ainda assim, o processo de encontrar a documentação correta é, por si só, um exercício irritante
      O princípio do DNS não é tão difícil quando você entende que ele é recursivo. Mas há muito a aprender se você quiser configurá-lo pensando em segurança, ter a infraestrutura correta e acertar até o último detalhe. Tirando o BIND da conversa, não é tão difícil assim