Esta é uma pergunta canônica sobre terceirizar a resolução DNS para os próprios domínios

Atualmente, tenho meu ISP fornecendo DNS para o meu domínio, mas eles impõem limitações na adição de registros. Portanto, estou pensando em executar meu próprio DNS.

Você prefere hospedar seu próprio DNS ou é melhor que seu ISP faça isso?

Existem alternativas que eu possa procurar?

Eu não executaria meu próprio servidor DNS - no meu caso, a empresa de hospedagem que hospeda meu site fornece serviço DNS gratuito. Existem também alternativas, empresas que não fazem nada além de hospedagem DNS ( DNS Made Easy vem à mente, mas existem muitas outras), que são o tipo de coisa que você provavelmente deveria procurar.

A razão de eu não fazer isso sozinho é que o DNS deve ser bastante confiável e, a menos que você tenha sua própria rede de servidores distribuídos geograficamente, você estará colocando todos os seus ovos em uma cesta, por assim dizer. Além disso, existem muitos servidores DNS dedicados por aí, o suficiente para que você não precise iniciar um novo.

Nós sempre hospedamos nosso próprio DNS (DNS reverso preferível também). Isso nos permite fazer alterações de emergência sem depender de terceiros. Se você tiver mais de um local, é fácil configurar um nível aceitável de redundância para seus servidores DNS.

Se você não tiver vários sites, consideraria alguém que hospeda DNS especificamente (NÃO o seu ISP) com uma interface da Web para alterações. Procure também suporte 24x7 e SLAs decentes.

Para uma configuração DNS boa e confiável para seu (s) domínio (s), você deve ter ...

• No mínimo dois servidores DNS autorizados para o seu domínio;
• Os servidores DNS devem estar conectados a diferentes redes físicas e fontes de alimentação;
• Os servidores DNS devem estar em diferentes áreas geográficas.

Como é improvável que você tenha acesso à infraestrutura de rede acima, é melhor escolher um provedor de hospedagem DNS respeitável (como outros recomendaram) que possua a infraestrutura de rede acima.

Por muitos anos, eu executei meus próprios servidores DNS usando o BIND (versões 8 e 9) sem grandes problemas. Armazenei minhas configurações no controle de versão com verificações pós-confirmação que validariam os arquivos de zona e, em seguida, meus servidores DNS faziam check-out dos arquivos de zona em intervalos regulares. O problema estava sempre em garantir que o número de série da SOA fosse atualizado com cada confirmação enviada, caso contrário, os servidores de cache não seriam atualizados.

Anos mais tarde, trabalhei com o djbdns, pois o formato era ideal para ter scripts automatizados para gerenciar as zonas e não sofria do mesmo problema de número de série da SOA que eu tive que lidar com o uso do BIND. No entanto, ele tem seus próprios problemas ao precisar formatar determinados conjuntos de registros de recursos para que eles sejam aceitos.

Como eu descobri que muito do meu tráfego era DNS e precisava manter um servidor DNS primário e secundário para agradar aos registradores que eu mudei para o EasyDNS para minhas necessidades de DNS. A interface da Web deles é fácil de gerenciar e me oferece a flexibilidade necessária para gerenciar meus conjuntos de RR. Também achei fácil trabalhar com aqueles fornecidos por alguns provedores de hospedagem, como 1 e 1, que limitam os conjuntos disponíveis de RR nos quais você pode entrar ou mesmo registradores de domínio como o Network Solutions, que só funciona se você usar o Windows para gerenciar seu DNS.

Para meus domínios pessoais (e domínios de alguns amigos com os quais ajudo), hospedamos nosso próprio DNS e meu registrador (Gandi) fornece DNS secundário. Ou um amigo em outra rede fornece secundário. Gandi não atualiza as zonas imediatamente, elas parecem checar aproximadamente uma vez a cada 24 horas, mas as mudanças são muito raras; funciona bem o suficiente para nós, e o servidor deles provavelmente é muito mais confiável que o nosso.

No meu trabalho, fazemos nosso próprio DNS e nosso provedor de rede upstream fornece DNS secundário. No entanto, somos uma universidade e 99% de nossos usuários estão no local; se a rede local estiver inativa, não importa se o DNS está inoperante. Além disso, temos uma classe B (/ 16) completa com aproximadamente 25k registros DNS (mais 25k registros DNS reversos, é claro), o que parece um pouco complicado de gerenciar por meio de uma interface da web. Nossos servidores DNS locais estão altamente disponíveis e são bastante rápidos.

Eu fiz os dois. Pode haver benefícios em hospedar o seu próprio: você definitivamente aprende muito sobre como o DNS funciona quando seu chefe está perguntando por que está demorando tanto. Além disso, você tem muito mais controle das suas zonas. Isso nem sempre é tão poderoso quanto deveria ser, em grande parte devido à natureza hierárquica distribuída do DNS - mas, de vez em quando, é útil. Duplamente, se você conseguir que seu provedor o aloque como SOA para o DNS reverso do seu bloco de IP, supondo que você tenha um.

No entanto, todos os comentários acima sobre como você realmente deve ter muita resistência a falhas incorporada acima são bons. Servidores em diferentes data centers em diferentes áreas geográficas são importantes. Tendo gerenciado a enorme queda de energia no Nordeste em 2003 - todos aprendemos que ter uma caixa em dois data centers diferentes na mesma cidade, ou mesmo província ou estado - não é necessariamente proteção suficiente. A alegria que surge quando você percebe que as baterias e os geradores a diesel salvaram sua bunda são rapidamente substituídos pelo pavor causado pela percepção de que você está dirigindo agora com seu pneu sobressalente.

Porém, sempre executo nosso servidor DNS interno para a LAN. Pode ser muito útil ter controle completo sobre o DNS que sua rede usa internamente - e se a energia acabar em seu escritório, seu servidor DNS interno por estar no rack de servidores provavelmente está com bateria ou bateria e diesel, enquanto o seu PC não estiver - portanto, seus clientes ficarão off-line muito antes do servidor.

Estou lendo todas essas soluções com alguma diversão porque conseguimos encaixar acidentalmente em todos esses "requisitos" hospedando nosso DNS primário em uma linha DSL estática e solicitando que o registrador (que estava em outro continente) forneça um DNS secundário em um conexão muito mais séria e confiável. Dessa forma, obtemos toda a flexibilidade de usar o bind e definir todos os registros ao mesmo tempo, sendo razoável garantir que o secundário seja atualizado para espelhar essas alterações e estará disponível no caso de um bueiro pegar fogo, para citar uma ocorrência.

Isso efetivamente cumpre:
"No mínimo dois servidores DNS autoritativos para o seu domínio;"
"Os servidores DNS devem estar conectados a diferentes redes físicas e fontes de alimentação;"
"Os servidores DNS devem estar em diferentes áreas geográficas."

Dê uma olhada no Dyn.com ; eles têm todos os tipos de serviços relacionados ao DNS, como hospedagem DNS, DNS dinâmico, MailHop, etc. Eu os achei confiáveis ​​e os uso há provavelmente 5 anos.

Depende.

Eu administro meu próprio DNS para meus vários trabalhos desde o final dos anos 80 (BSD 4.3c). No trabalho, sempre hospedei meu próprio DNS, mas sempre tive vários locais de datacenter ou pude trocar DNS secundário com um parceiro. Por exemplo, no meu último trabalho, fizemos DNS secundário para um .EDU diferente (eles estavam em MN, estamos em CA) e fizeram o mesmo por nós. Diversidade geográfica e de rede.

Ou, no meu trabalho atual, temos nossos próprios datacenters da costa leste e oeste (EUA). Hospedar nosso próprio DNS nos permite inserir os registros DNS incomuns que precisamos (SVR, TXT etc.) que talvez não sejam suportados por alguns serviços de DNS da GUI. E podemos alterar os TTLs sempre que quisermos; temos praticamente uma flexibilidade definitiva, ao custo de fazê-lo nós mesmos.

Para coisas domésticas, eu fiz as duas coisas. Em alguns domínios em que faço coisas incomuns ou preciso de muita flexibilidade, ainda executo meus próprios servidores DNS "ocultos" e troco serviços DNS públicos com outras pessoas que fazem o mesmo. Eu uso o RCS para controlar arquivos de zona de controle de versão para gerenciamento de configuração, para que eu possa ver todo o histórico de alterações de zona desde o início dos tempos. Para coisas simples, como um domínio com um único blog ou servidores Web genéricos (um registro A ou um CNAME), é mais fácil usar um serviço DNS de registradores de domínio, quando disponível, e agora se preocupar com o CM.

É uma troca. O controle e a flexibilidade finais têm o custo de lidar com a diversidade por conta própria, executar vários servidores, lidar com falhas de hardware / software etc. Se você não precisar da flexibilidade ou do controle total, qualquer um dos provedores de DNS de primeira linha precisará resolva seu problema, provavelmente a um custo total mais baixo.

Como já mencionado neste encadeamento, existem vários casos especiais com DNS, a diferença mais significativa é entre implantações autorizadas e em cache de servidores de nomes.

1. Se você precisar de um servidor DNS apenas para resolver os recursos da Internet, algum resolvedor de DNS gratuito é uma escolha sábia. Eu pessoalmente uso o recursor do PowerDNS (pdns-recursor) no Linux.

2. Para atender sua infraestrutura externa, como sites ou MXs, eu não usaria NSes internos (se estivermos falando sobre SOHO aqui). Use algum serviço bom, confiável e à prova de balas, como o DNSmadeasy . Eu uso o pacote de negócios deles, e ele é ótimo, além de muito acessível.

Eu usei o Zonedit ou anos. É barato (ou gratuito) e adicionei muitos registros CNAME, A, MX, TXT, SRV e outros.

Recentemente, trouxemos nosso DNS público internamente quando trouxemos todos os nossos serviços internamente. Isso nos permite atualizar tudo o mais rápido possível. Ter DNS distribuído geograficamente não é um requisito para nós no momento, pois os servidores da Web estão todos no mesmo site.

Eu tenho o melhor dos dois mundos.

Eu hospedo meu DNS público para meus sites e meus registros MX "em outro lugar". É confiável, seguro, funciona, posso modificá-lo à vontade. Eu pago pelo serviço e estou feliz com o valor.

Mas em casa, eu executo meu próprio servidor DNS de cache, em vez de confiar no meu ISP. Meu provedor de serviços de Internet tem o hábito de perder o DNS, ter DNS lento, DNS inválido e, às vezes, eles querem perverter o DNS, para que as falhas cheguem a lugares nos quais eles acham que eu possa estar interessado. Não estou interessado em usar o DNS do meu ISP. Então, eu tenho meus próprios servidores DNS em cache e faço isso sozinho. Foi um pouco de esforço para configurar no início (talvez 2 horas), mas é limpo e eu tenho um DNS confiável. Uma vez por mês, um trabalho cron interroga os servidores raiz e atualiza a tabela de dicas. Talvez uma vez por ano eu tenha que mexer com isso, como enviar doubleclick.com para 127.0.0.1 ou similar. Fora isso, não requer intervenção e funciona muito bem.

Se você decidir hospedar seu próprio DNS pelo amor de Deus, tenha DOIS servidores DNS por site. Um para o seu DNS externo, conectado diretamente ao seu firewall para que o mundo o encontre. E um separado dentro da sua rede para o seu DNS interno.

Ainda não posso comentar, mas estou fazendo o mesmo que freiheit. Executamos nosso DNS primário aqui em nossa DMZ, e nosso ISP possui vários servidores DNS escravos em todo o país, que são atualizados imediatamente após a alteração no DNS primário.

Dá o melhor dos dois mundos; controle imediato mais redunância.

Existem prós e contras em cada abordagem, mas eu definitivamente sou a favor de hospedar seu DNS interno internamente. A lista de itens nos quais você depende de serviços básicos de rede, se você o hospedar externamente, é incompreensível. O CEO pode achar que é inteligente economizar dinheiro em servidores DNS hospedando externamente, mas o que ele pensará quando não conseguir receber seu email se o link da Internet cair?

Por experiência, se você deseja atrair um ataque de negação de serviço, hospede seu próprio DNS. E seu próprio site.

Eu acredito que há algumas coisas que você não deve fazer sozinho. Hospedagem de DNS é um deles. Como muitas pessoas disseram, você precisaria de servidores, conexões e locais físicos redundantes e ainda não abordaria a resiliência das empresas de hospedagem menores.

O maior benefício de hospedar seu próprio DNS é que as alterações podem ser feitas imediatamente. Precisa reduzir seus TTLs para uma migração futura? Você provavelmente poderia escrever um script que faça isso em seus próprios servidores; para DNS hospedado, pode ser necessário efetuar login e alterar manualmente os registros, ou, pior ainda, ligar para o provedor, passar por três níveis de suporte até chegar finalmente a alguém que possa soletrar o DNS, apenas para que eles avisem que enviarão o alterações em 2-3 dias.

Eu executo meu próprio DNS usando o BIND nos servidores Linux. Atualmente, tenho quatro localizados em Londres, Reino Unido, Miami FL, San Jose CA e Cingapura. Funciona muito bem e eu tenho controle completo. A estabilidade do datacenter é muito importante, portanto, selecionei bons DCs para executar os servidores (não dependentes do ISP ou de alguma outra infraestrutura 'desconhecida'). Sou capaz de configurar servidores DNS e outros serviços em qualquer lugar do mundo usando os CDs de classe mundial que seleciono com base em critérios rigorosos. Um DNS sólido é essencial para os serviços de email e web que eu executo.

Devemos hospedar nossos próprios servidores de nomes?

Sim, e você também deve usar um ou mais dos grandes provedores de DNS de terceiros. Uma solução híbrida é provavelmente a abordagem mais segura a longo prazo por vários motivos, especialmente se você é um negócio que possui qualquer nível de SLA ou requisitos contratuais para seus clientes. Ainda mais se você é b2b.

Se os servidores DNS principais (ocultos ou públicos) são sua fonte de verdade, você se protege operacionalmente de ficar preso a recursos específicos do fornecedor. Depois de começar a usar os recursos interessantes que vão além do DNS básico, você pode achar que mudar para outro provedor ou hospedar seu próprio DNS é problemático, pois agora você precisa replicar esses recursos. Exemplos seriam as verificações de integridade do site e o failover de DNS que Dyn e UltraDNS fornecem. Esses recursos são ótimos, mas devem ser considerados únicos e não dependentes. Esses recursos também não se replicam bem de provedor para provedor.

Se você tiver apenas fornecedores de terceiros, seu tempo de atividade poderá ser afetado quando eles estiverem sob um ataque DDoS direcionado. Se você tiver apenas seus próprios servidores DNS, seu tempo de atividade poderá ser afetado quando você for o alvo de um ataque DDoS.

Se você tiver um ou mais provedores de DNS e seus próprios servidores DNS distribuídos que escravizam os servidores DNS principais ocultos que você controla, assegurará que não esteja bloqueado em um fornecedor específico e mantenha o controle de suas zonas o tempo todo e que os ataques devem derrubar seus servidores e um ou mais provedores principais que escravizam seus servidores. Qualquer coisa menos que isso será uma degradação do serviço versus uma interrupção crítica.

Outra vantagem de ter seus próprios servidores principais (ocultos idealmente, não publicados) é que você pode criar sua própria API e atualizá-los da maneira que mais lhe agrada. Com provedores de DNS de terceiros, você precisará se adaptar à API deles. Cada fornecedor tem o seu próprio; ou, em alguns casos, apenas possui uma interface da web.

Além disso, se o seu mestre está sob seu controle e um fornecedor está tendo um problema, qualquer um dos seus servidores escravos que ainda podem chegar ao seu mestre receberá as atualizações. Isso é algo que você gostaria que tivesse depois de perceber que ter um terceiro como seu mestre foi um erro durante um grande incidente de DDoS e você não pode alterar nenhum servidor em fornecedores que não estão sob ataque.

Do ponto de vista jurídico, impedir o bloqueio do fornecedor também pode ser importante para os seus negócios. Por exemplo, Dyn está sendo comprado potencialmente pela Oracle. Isso os coloca em uma posição única para reunir estatísticas de DNS em todos os clientes da Dyn. Existem aspectos competitivos disso que podem introduzir riscos legais. Dito isto, eu não sou advogado, portanto, você deve consultar suas equipes jurídicas e de relações públicas sobre esse assunto.

Existem muitos outros aspectos nesse tópico se quisermos cavar as ervas daninhas.

[Editar] Se for apenas para um pequeno domínio pessoal / hobby, então 2 VMs que não estão no mesmo datacenter que a outra, executar um pequeno daemon DNS é mais que suficiente. Eu faço isso para meus próprios domínios pessoais. Não estava claro para mim se o seu domínio significava um negócio ou apenas por hobby. Quaisquer que sejam as menores VMs que você pode obter, são mais do que suficientes. Eu uso o rbldnsd para meus domínios; usando um TTL muito alto em meus registros, pois ocupa 900 KB de memória RAM e pode lidar com qualquer abuso que as pessoas cometam.

Pense na hospedagem DNS como base para seus serviços públicos. No meu caso, o e-mail é fundamental para os nossos negócios. Se você hospedar seu DNS internamente e sua conexão à Internet falhar, seus registros DNS poderão ficar obsoletos, forçando seu domínio a não estar disponível.

Portanto, no meu caso, se um registro MX não puder ser encontrado em nosso domínio, o email será rejeitado imediatamente.

Então, eu tenho nosso DNS hospedado externamente.

Se o registro MX estiver disponível, mas nossa conexão com a Internet estiver inoperante, os e-mails continuarão na fila nos servidores que tentam enviar e-mails para o nosso domínio.

Depende. ™

Estou executando meus próprios servidores e gerenciando domínios desde pelo menos 2002.

Eu sempre usei o servidor DNS do meu provedor.

O número de vezes que meu servidor no meu IP estava disponível, mas meu DNS não estava, foi um número excessivo.

Aqui estão minhas histórias de guerra:

• Um provedor yuge em Moscou (um dos primeiros baseados em VZ) tinha meu VPS em um CD de "valor" barato, mas o DNS deles estava em um CD de última geração com tráfego caro, em dois sub-redes / 24 diferentes, conforme exigido por alguns TLDs na época . A certa altura, um desastre ocorreu (possivelmente a falta de energia de 2005? ) E seu CD caro ficou offline, e meu site (ainda em Moscou, mas em um CD "de valor") só pôde ser acessado por seu endereço IP.

  É interessante traceroutenotar que , mesmo antes de qualquer incidente, lembro-me claramente de fazer e, observando o mesmo CD para ambos ns1e ns2para o meu ISP, pedindo-lhes para mover um para o "meu" CD também, por redundância geográfica; eles descartaram a ideia da redundância geográfica, porque os servidores já estavam no controlador de domínio mais premium possível.

• Eu tive outro provedor (um dos primeiros baseados no ISPsystem), onde eles tinham um ns no local e outro no exterior. Para encurtar a história, toda a instalação era ridiculamente incorreta e o servidor "estrangeiro" geralmente falhou em manter suas zonas; portanto, meu domínio efetivamente tinha um ponto de falha extra e não seria acessível mesmo que todo o servidor ainda funcionasse sem problemas.

• Eu tive um registrador que administrava sua própria rede. Ele caiu de vez em quando, apesar de meus servidores externos estarem funcionando. Meu DNS estava inoperante.

• Recentemente, usei vários grandes fornecedores de nuvem para o secundário, onde eu próprio executava um mestre oculto. Ambos os provedores alteraram suas configurações pelo menos uma vez; nunca com anúncios públicos; alguns dos meus domínios pararam de ser resolvidos. Também aconteceu com um amigo meu, com um dos mesmos fornecedores. Isso acontece com mais freqüência com serviços de terceiros do que as pessoas desejam admitir em público.

Em resumo, http://cr.yp.to/djbdns/third-party.html está absolutamente correto no tópico.

Os custos de se preocupar com o DNS de terceiros geralmente não valem os benefícios.

Os negativos de ter um DNS de terceiros geralmente são injustamente ignorados.

Eu diria que, a menos que seu domínio já use serviços de terceiros (por exemplo, para web, correio, voz ou texto), a adição de um DNS de terceiros quase sempre seria contraproducente e não é de forma alguma a melhor prática em todas as circunstâncias .