Devemos hospedar nossos próprios servidores de nomes?

93

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?

Saif Khan
fonte
Além das respostas abaixo, a experiência também é importante. Existem inúmeros erros que você vai fazer como um administrador de DNS incipiente barrando boa orientação ou um olho de águia para documentação. (livros e RFCs, não HOWTOs) Erros cometidos na camada DNS autoritativa causam interrupções mesmo quando o restante da rede está bom .
Andrew B
Leia também as perguntas e respostas relacionadas Por que o DNS com redundância geográfica é necessário mesmo para sites pequenos?
HBruijn

Respostas:

64

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.

David Z
fonte
7
+1 para o DNS facilitado. Eles têm um registro de atualização auditado de 100,0% nos últimos 7 anos ou mais.
Portman
Só pensei em deixar um bilhete. Hoje mesmo, finalmente, nos cansamos do DNS ruim do nosso provedor atual, mudamos para o DNS Made Easy com base na recomendação aqui, e é muito complicado. Adoro. Gostaria de ter feito isso anos atrás.
Mark Henderson
1
Não é por isso que existe um servidor primário e secundário para cada entrada? Eu nunca tive uma falha sendo a principal e tendo a secundária como minha registradora; Quero dizer, eu tive uma falha no primário, mas ninguém percebeu porque havia um secundário confiável.
dlamblin 14/09/09
Claro, nada de errado nisso, se você realmente deseja executar seu próprio servidor DNS por algum motivo. Mas, caso contrário, desde que você pague a terceiros pela hospedagem de DNS de qualquer maneira (para ser o secundário), é melhor deixá-los lidar com tudo. Para a maioria das pessoas, acho que rodar um servidor DNS é mais complicado do que vale a pena.
David Z
Na verdade, o DNS Made Easy possui uma rede de servidores em vários continentes. E eles usam roteamento anycast. Portanto, sua redundância é ridícula, muito além da configuração convencional de dois servidores (primário e secundário). Mas, em teoria, isso também significa que computadores em todo o mundo terão uma rápida resolução de DNS.
Steve Wortham
27

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.

Doug Luxem
fonte
4
Ao considerar a terceirização, pergunte também que tipo de proteção ou mitigação de DDoS eles possuem. Os provedores de DNS são atacados o tempo todo e alguns são capazes de continuar correndo sem suar a camisa e outros se esfarelam em uma pilha de migalhas ao menor pico de tráfego, portanto, fique cansado de terceirizar, a menos que seja um provedor respeitável que tenha muitos servidores implantados com roteamento anycast ativado.
Justin Scott
Eu estava prestes a votar (com muito entusiasmo!) Com base na sua experiência pessoal na primeira frase, mas você sugere usar um serviço de terceiros na segunda, o que basicamente significa que um ponto extra de falha desnecessário foi adicionado para pouco ou nenhum benefício. : / Triste.
CNST
19

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.

Condenar
fonte
Difícil não se convencer quando você coloca dessa maneira.
Filip Dupanović
Este é um ótimo resumo do consenso da indústria, com exceção de nenhum. (Você sabe, o setor que lucra com soluções caras e superengenharia que podem até não funcionar de verdade com as especificações reais.)
cnst
Qual a vantagem de ter servidores DNS altamente redundantes se a sua hospedagem ainda não é redundante?
Chris Smith
13

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.

Jeremy Bouse
fonte
Esta é uma boa resposta honesta, mas parece que você pode estar se enganando na firmeza da sua solução - usando o EasyDNS, você está tornando o seu único ponto de falha; seu site pode estar em pleno funcionamento, mas seus nomes podem não estar sendo resolvidos caso seu fornecedor terceirizado sofra uma interrupção ou um DDoS direcionado a um de seus clientes.
CNST
8

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.

freiheit
fonte
3
Nós fazemos a mesma coisa aqui. Temos duas caixas Linux executando o BIND (um pri no outro segundo) e nosso 'ISP' também está executando o DNS secundário.
L0c0b0x
1
Idem. Também com uma classe B, também executando nossos próprios servidores DNS BIND. E quando temos problemas de DNS, geralmente é com nosso site
externo
Ótima resposta; até agora, esta é minha resposta favorita para essa pergunta, porque ela é realmente baseada em boas práticas de engenharia e na estimativa realista da redundância e disponibilidade disponíveis, bem como na experiência pessoal; enquanto tantas outras respostas simplesmente listam seu provedor de DNS favorito de terceiros ou copiam cegamente os resumos escritos por pessoas com um claro conflito de interesses de ganhar dinheiro extra com as soluções de engenharia que eles propõem.
CNST
5

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.

Kyle Hodgson
fonte
4

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."

dlamblin
fonte
Esta é certamente uma abordagem de se sentir bem; mas se um bueiro pegar fogo e toda a sua infra-estrutura ficar sem DNS, qual o sentido do DNS ainda estar disponível quando nenhum servidor puder ser contatado? :-) Acho que enfrentar o problema do DNS secundário de terceiros só faz sentido se você também terceirizar alguns outros serviços para outros terceiros.
CNST
@ cmst O ponto é que, quando o DNS está inoperante, qualquer pessoa que enviar um e-mail a você verá um problema imediato (clientes? parceiros? publicidade muito ruim) Se o DNS funcionar e o servidor de email estiver inativo por algumas horas, eles geralmente não notam nada.
precisa saber é o seguinte
O @cmst DNS não se limita a apontar para servidores na minha rede pessoal. Eu posso nomear IPs em qualquer lugar. Talvez eu tenha um nome para cada uma das caixas NAT da rede doméstica de meus funcionários / amigos. Ou eu poderia usar outros tipos de registro e identificar / verificar publicamente algo.
precisa saber é o seguinte
4

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.

Knox
fonte
2
+1, eu uso o DynDNS há cerca de 2 anos e estou completamente satisfeito com o serviço deles.
Cdmckay 11/06/09
Dyn.com costumava ser Dyndns antes em torno de 2013.
Knox
3

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.

tep
fonte
Embora seja mais fácil simplesmente usar o DNS do registrador, não é tão incomum que o DNS de um registrador esteja inativo, enquanto o registro do domínio e seu próprio host estão ativos, mas o site não está disponível, porque você adicionou um ponto de falha extra à sua configuração para facilitar. Não é realmente tão difícil executar seu próprio DNS; especialmente hoje em dia com a infinidade de servidores leves e fáceis de usar.
CNST
3

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.

Taras Chuhay
fonte
Muitas pessoas também endossam a visão do DJB de nunca executar um cache DNS (o resolvedor recursivo) no mesmo sistema que um servidor DNS (o armazenamento de arquivos da zona). Isso é por razões de segurança, para que os furos de um não afetem o outro e vice-versa.
precisa saber é o seguinte
2

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

Steve Jones
fonte
2

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.

mrdenny
fonte
2
Seu email também está hospedado nesse site? Lembre-se de que, se você perder a conectividade e o email estiver fora dessa rede, seus registros MX desaparecerão e o email deixará de funcionar, mesmo se estiver alojado em outro local. Se também estiver no mesmo site, não é grande coisa, mas já vi esse argumento desmoronar por esse motivo várias vezes no passado.
Justin Scott
1
Sim, esses caras estão enviando seus emails no mesmo site (não estou mais nessa empresa).
mrdenny
2

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.

codebunny
fonte
O problema com o DNS de terceiros é que, se estiver inativo, mesmo que seu site esteja ativo, as pessoas não poderão acessar seu domínio. (Tanta redundância!)
cnst
2

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.

XTZ
fonte
Essa prática é chamada de horizonte dividido. Provavelmente não é aplicável à maioria das configurações, francamente, e está bastante desatualizado, fora da grande empresa, há um bom tempo.
CNST
@cnst O split-horizon (ou split-view) está atendendo a uma zona diferente sob o mesmo nome de domínio e a XTZ não disse que o recomenda. Um servidor interno geralmente serve um nome de domínio diferente (talvez subdomínio).
precisa saber é o seguinte
2

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.

pauska
fonte
2

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?

Maximus Minimus
fonte
Ótima resposta, +1! Avançando para 2017, você ainda acha que o DNS interno é o caminho a percorrer? :-)
cnst
1
@cnst ffwd to 2017 Já não tenho experiência suficiente para fazer uma recomendação.
Maximus Minimus
2

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.

David Oresky
fonte
2

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.

Justin Jones
fonte
LOL, ótimo anúncio, posso obter o número do seu departamento de marketing e o editor de cópias? Estou marcando como um óbvio candidato a spam, mas ao mesmo tempo não ficarei surpreso se esse sinalizador também for recusado!
CNST
2

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.

Aaron
fonte
Embora excessivamente centrada na empresa, essa seja uma boa resposta razoável, quem poderia dar o -1 por favor pode se explicar?
CNST
Dois bons pontos frescos sobre a API e as fusões de fornecedores. Dois controladores de domínio estão OK, mas também observe que há um ISP separado para cada um, não o mesmo ISP.
precisa saber é o seguinte
Bom ponto @kubanczyk muiltiple ingres links para failover seguro e automatizado e verificações de integridade neles.
Aaron
1

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.

Brian
fonte
Eu não acho que isso seja verdade em relação aos MXregistros; de fato, é um dos conceitos errôneos documentados em cr.yp.to/djbdns/third-party.html .
CNST
0

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 .

cnst
fonte