Sempre me perguntei como a infraestrutura DNS para (digamos, um TLD .com) é projetada. Ele não deve apenas ser capaz de manter um alto nível de confiabilidade, mas também suportar grandes quantidades de atualizações em tempo real dos registros.
Eu diria que o BIND do ISC é usado nesse nível. Tenho uma ideia bastante clara de como alguém construiria uma infraestrutura escalonável usando o BIND. A parte que não tenho certeza é como alguém projetaria um sistema que pudesse lidar com a adição, exclusão e alteração de centenas de zonas DNS a cada poucos segundos. Existem inúmeros registradores de domínio no mundo e apenas .com provavelmente apresenta uma enorme quantidade de atividade. Como um sistema construído em arquivos de zona BIND pode ser dimensionado para tantas mudanças?
Estou certo em duvidar que um operador de TLD esteja usando arquivos de texto e fazendo com que o BIND recarregue constantemente as alterações sempre que um novo .com é registrado? Se sim, o que eles fazem? É um banco de dados SQL ou LDAP? isso é mesmo escalonável?
Responder1
Primeiro, você realmente acha que há mais atualizações do que, digamos, transações de cartão de crédito por segundo no mundo, gerenciadas finalmente por apenas 2 ou 3 empresas? Isso funciona, então é um problema solucionável :-)
Em segundo lugar, você pode ficar confuso sobre como as atualizações estão acontecendo, porque é uma parte pouco compreendida onde dois planos se cruzam: o plano de registro e o plano de publicação. Você também pode ficar confuso com o que exatamente acontece nos servidores de nomes de registro (mantendo apenas os NSregistros para delegações de domínios, e NÃO o conteúdo completo dessas zonas).
Mas antes de entrar nisso, você também parece assumir que as atualizações devem ser em tempo real, onde ambas não são necessárias e muitas vezes não são. De qualquer forma, nada é em tempo real no DNS, por causa do TTL.
Então, de volta aos seus dois aviões:
- os registradores enviam atualizações aos registros quando os servidores de nomes mudam e outras operações que têm efeitos colaterais do DNS (ex: configuração
clientHolddo status do EPP); este é o plano de registro, é completamente NÃO CORRELADO à publicação do DNS e normalmente usa um protocolo chamado EPP; quando o registro responde "atualização aceita", isso não significa que já esteja publicado em sua infraestrutura DNS, é apenas uma garantia "será em algum momento" - os registros mantêm o plano de publicação do DNS, garantindo que seus servidores de nomes publiquem os
NSregistros corretos para todas as delegações, também conhecidos como todos os domínios registrados nos TLDs que gerenciam.
Como tal, o número de alterações é provavelmente muito menor do que você tem em mente: se um .comproprietário altera o conteúdo de sua zona, com novos registros, na maioria dos casos, não há nada a fazer através do registrador e nada muda no registro autoritativo. servidores de nomes.
E essas mudanças NÃO acontecem através do mecanismo de atualização de DNS. As alterações são enviadas pelos registradores usando um protocolo específico, EPP. As alterações são armazenadas de alguma forma em algum banco de dados do registro, após o qual os novos dados são publicados pelo registro em seus servidores de nomes autorizados.
Você também parece pensar que "tempo real" é obrigatório. Não é, pelo menos não tecnicamente, e pode até ser por um design ineficaz (considere se você deseja fazer testes se as novas alterações fazem sentido, como alguns registros estão fazendo, verificando se os servidores de nomes estão configurados corretamente para resolução do nome em breve serão listados como autorizados para testes DNSSEC, por exemplo...).
Uma forma típica de configuração, usada por muitos registros que fornecem coisas como um "atraso de 10 minutos para atualizações" ou "1 hora", é armazenar em algum buffer interno todas as alterações solicitadas naquele determinado período de tempo e, em seguida, de uma vez por todas gerar a nova zona e publicá-la, enquanto inicia um novo buffer para coletar todas as alterações que ocorrerão no próximo período.
Eu diria que o BIND do ISC é usado nesse nível.
De jeito nenhum. A Verisign executa seu próprio software proprietário de servidores de nomes, chamado Atlas. Veja por exemplohttps://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html Observe que neste artigo de 2004 já é dito:
VeriSign Naming and Directory Services (VNDS) promete atualizar os 13 principais servidores de nomes autorizados .com e .net em menos de cinco minutos. A taxa atual é de cerca de duas vezes por dia.
Claro que melhora desde então. Mas acredito que mesmo uma vez a cada 5 minutos seja suficiente para qualquer uso prático real do DNS.
Também poderia haver obrigações contratuais, especificamente para registros e registradores de gTLDs que estejam todos sob contrato com a ICANN. O contrato atual da Verisign-ICANN está emhttps://www.icann.org/en/registry-agreements/details/com Você pode encontrar no §6.6 do apêndice emhttps://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-endetalhes sobre as restrições de atualização:
6.6 Frequência de atualização. O Operador de Registro atualiza oportunamente os dados nos Servidores de Nomes DNS e Whois. Os registradores credenciados pela ICANN registram essas atualizações por meio do SRS. O SRS atualiza então o servidor de nomes DNS e o Whois. O Operador de registro processa essas atualizações quase em tempo real.
A especificação de desempenho comprometida com relação à frequência de atualização para o servidor de nomes DNS e Whois é de 3 minutos para 95% das transações durante um período mensal. Ou seja, 95% das atualizações dos servidores de nomes DNS e Whois durante um período mensal serão concluídas em 3 minutos. A frequência de atualização é medida desde o momento em que o Operador de registro confirma a atualização até o momento em que a atualização aparece no servidor de nomes DNS e no Whois. O desempenho da frequência de atualização será informado mensalmente à ICANN, de acordo com o Apêndice 4.
Observe a marca usual de “95%” usada para muitos SLA. Portanto, é quase em tempo real quando viável, mas na prática normalmente leva 3 minutos (daí a configuração típica do buffer descrita acima).
Tenho uma ideia bastante clara de como alguém construiria uma infraestrutura escalonável usando o BIND. A parte que não tenho certeza é como alguém projetaria um sistema que pudesse lidar com a adição, exclusão e alteração de centenas de zonas DNS a cada poucos segundos.
A Verisign possui apenas algumas zonas: .com, .net, alguns IDNs, etc. Eles não gerenciam "centenas de zonas". E certamente não centenas deles com muitas mudanças a cada segundo.
Você pode/quer estar mais interessado em provedores de DNS que hospedam milhões de zonas com possível alta frequência de atualizações. Aqui está um artigo da CloudFlare onde eles explicam o que fazem em termos de desempenho em relação ao seu serviço DNS oficial:https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/
Existem inúmeros registradores de domínio no mundo
Não, não todos. Longe de serem incontáveis. Na verdade, menos de 2.000, e provavelmente apenas cerca de 500 realmente ativos com grandes volumes de mudanças. Todos os registradores de gTLDs devem ser credenciados pela ICANN. Você pode encontrar a lista completa deles emhttps://www.icann.org/en/accredited-registrars
Estou certo em duvidar que um operador de TLD esteja usando arquivos de texto e fazendo com que o BIND recarregue constantemente as alterações sempre que um novo .com é registrado?
Nenhum software de servidor de nomes de transações de alto nível seria apoiado por arquivos de texto. Mesmo o Bind não é: quando as atualizações dinâmicas estão habilitadas, você tem um arquivo de "diário" (que é binário) e você especificamente não deve editar a versão do arquivo de texto da zona (sem primeiro congelar as atualizações e depois permiti-las novamente após o editar).
Se sim, o que eles fazem? É um banco de dados SQL ou LDAP? isso é mesmo escalonável?
Duvido que SQL ou LDAP sejam bons mecanismos de armazenamento para DNS. Lembre-se de que o DNS é de natureza hierárquica, o que apresenta várias restrições.
Responder2
Em primeiro lugar, em alguns casos não é necessário recarregar imediatamente.
Se você tiver um SLA dizendo "pague-nos e terá seu domínio registrado em X horas", você pode até recarregar periodicamente usando algum cron job ou similar. Portanto, alguns registradores podem usar arquivos simples e recarregá-los periodicamente.
Tenha em mente que você pode ter vários servidores DNS associados ao mesmo endereço IP (por exemplo, usando anycast), então você pode até configurar um mecanismo de "implantação contínua", que altera o arquivo simples em todos os lugares e recarrega um servidor DNS por vez. tempo.
Dito isso, o Bind >9 oferece suporte a DLZ (Zonas carregáveis dinamicamente), o que essencialmente permite que o Bind use um banco de dados como back-end de dados de zona. Os bancos de dados (e conexões de banco de dados) podem então ser dimensionados de acordo com estratégias clássicas de dimensionamento de banco de dados, desde que você tenha um driver DLZ válido para seu banco de dados.
Finalmente, como disse um comentário, o escalonamento vertical (ou seja, ter muita CPU, RAM e IOPS para cada servidor) ajuda.
Há um 2009SANOGslide que você pode achar interessante, embora esteja obviamente um pouco desatualizado:https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf