¿Deberíamos alojar nuestros propios servidores de nombres?

93

Esta es una pregunta canónica sobre si externalizar la resolución DNS para los dominios propios

Actualmente tengo mi ISP que proporciona DNS para mi dominio, pero imponen limitaciones para agregar registros. Por lo tanto, estoy pensando en ejecutar mi propio DNS.

¿Prefiere alojar su propio DNS o es mejor que su ISP haga esto?

¿Hay alternativas que pueda analizar?

Saif Khan
fuente
Además de las respuestas a continuación, la experiencia también es importante. Hay numerosos errores que se va a hacer como administrador de DNS incipiente de restricción de buena tutoría o un ojo de águila para la documentación. (libros y RFC, no COMO) Los errores cometidos en la capa de DNS autorizada causan interrupciones incluso cuando el resto de su red está bien .
Andrew B
Lea también las preguntas y respuestas relacionadas. ¿Por qué es necesario un DNS geo redundante incluso para sitios pequeños?
HBruijn

Respuestas:

64

No ejecutaría mi propio servidor DNS; en mi caso, la empresa de alojamiento que aloja mi sitio web proporciona un servicio DNS gratuito. También hay alternativas, compañías que no hacen nada más que el alojamiento de DNS ( DNS Made Easy viene a la mente, pero hay muchas otras) que es el tipo de cosas que probablemente debería considerar.

La razón por la que no lo haría yo mismo es que se supone que el DNS es bastante confiable, y a menos que tenga una red de servidores distribuidos geográficamente, estaría poniendo todos sus huevos en una canasta, por así decirlo. Además, hay muchos servidores DNS dedicados, suficientes para que no necesite iniciar uno nuevo.

David Z
fuente
77
+1 a DNS hecho fácil. Tienen un registro de actualización 100% auditado en los últimos 7 años o más.
Portman
Solo pensé en dejarle una nota. Justo hoy finalmente nos hartamos de DNS basura de nuestro proveedor actual, cambiamos a DNS Made Easy en base a la recomendación aquí, y es fan-bloody-tastic. Quiéralo. Ojalá lo hubiera hecho hace años.
Mark Henderson
1
¿No es por eso que hay un servidor primario y secundario para cada entrada? Nunca he tenido un problema técnico siendo el principal, y teniendo el secundario como mi registrador; Quiero decir que he tenido un problema técnico en la primaria, pero nadie se dio cuenta porque había una secundaria confiable.
dlamblin
Claro, no hay nada de malo en eso si realmente quieres ejecutar tu propio servidor DNS por alguna razón. Pero, de lo contrario, siempre que va a pagar a un tercero por el alojamiento de DNS de todos modos (para ser el secundario), también puede dejar que se encargue de todo. Creo que para la mayoría de las personas, ejecutar un servidor DNS es más problemático de lo que vale.
David Z
DNS Made Easy en realidad tiene una red de servidores que abarca varios continentes. Y usan enrutamiento anycast. Por lo tanto, su redundancia es ridícula, mucho más allá de la configuración convencional de dos servidores (primario y secundario). Pero, en teoría, eso también significa que las computadoras de todo el mundo obtendrán una resolución rápida de DNS.
Steve Wortham el
27

Siempre alojamos nuestro propio DNS (DNS inverso preferible también). Esto nos permite realizar cambios de emergencia sin depender de un tercero. Si tiene más de una ubicación, es fácil configurar un nivel de redundancia aceptable para sus servidores DNS.

Si no tiene varios sitios, consideraría a alguien que específicamente realiza alojamiento de DNS (NO su ISP) con una interfaz web para los cambios. También busque soporte 24x7 y SLA decentes.

Doug Luxem
fuente
44
Al considerar la contratación externa, también pregunte qué tipo de protección o mitigación de DDoS tienen implementadas. Los proveedores de DNS son atacados todo el tiempo y algunos pueden seguir corriendo sin sudar y otros se desmoronan en una pila de migas al menor pico de tráfico, por lo que debe estar cansado de la subcontratación a menos que sea un proveedor de confianza que tenga muchos servidores implementados con Enrutamiento anycast habilitado.
Justin Scott, el
Estaba a punto de votar (¡con mucho entusiasmo!) Basado en su experiencia personal en la primera oración, pero luego sugiere utilizar un servicio de terceros en la segunda, lo que básicamente significa que se agrega un punto de falla adicional innecesario para poco o ningún beneficio : / Triste.
cnst
19

Para una configuración de DNS buena y confiable para sus dominios, debe tener ...

  • Un mínimo de dos servidores DNS automáticos para su dominio;
  • Los servidores DNS deben estar conectados a diferentes redes físicas y fuentes de alimentación;
  • Los servidores DNS deben estar en diferentes áreas geográficas.

Dado que es poco probable que tenga acceso a la infraestructura de red anterior, es mejor que elija un proveedor de alojamiento DNS de buena reputación (como lo han recomendado otros) que tiene la infraestructura de red anterior.

Condenar
fuente
Es difícil no convencerse cuando lo pones de esa manera.
Filip Dupanović
Este es un gran resumen del consenso de la industria, sin excepción. (Sabes, la industria que gana dinero con costosas soluciones de ingeniería excesiva que tal vez ni siquiera cumplan con las especificaciones reales reales.)
Cnst
¿De qué sirve tener servidores DNS altamente redundantes si su hosting aún no es redundante?
Chris Smith
13

Durante muchos años ejecuté mis propios servidores DNS usando BIND (versiones 8 y 9) sin mayores problemas. Almacené mis configuraciones dentro del control de versiones con comprobaciones posteriores a la confirmación que validarían los archivos de zona y luego hice que mis servidores DNS revisaran los archivos de zona a intervalos regulares. El problema siempre fue garantizar que el número de serie SOA se actualizara con cada confirmación que se eliminaba, de lo contrario los servidores de almacenamiento en caché no se actualizarían.

Años después trabajé con djbdns ya que el formato era ideal para tener scripts automatizados para administrar las zonas y no sufría el mismo problema de número de serie SOA con el que tuve que lidiar usando BIND. Sin embargo, tenía sus propios problemas al tener que formatear ciertos conjuntos de registros de recursos para que sean aceptados.

Como descubrí que gran parte de mi tráfico era DNS y tener que mantener un servidor DNS primario y secundario para complacer a los registradores a los que me he mudado para usar EasyDNS para mis necesidades de DNS. Su interfaz web es fácil de administrar y me brinda la flexibilidad que necesito para administrar mis conjuntos RR. También encontré que es fácil trabajar con los que proporcionan algunos proveedores de alojamiento como 1 y 1 que limitan los conjuntos de RR disponibles que puede ingresar, o incluso registradores de dominio como Network Solutions, que solo funciona si usa Windows para administrar su DNS.

Jeremy Bouse
fuente
Esta es una buena respuesta honesta, pero parece que puede estar engañándose a sí mismo en la solidez de su solución: al usar EasyDNS, lo está convirtiendo en su único punto de falla; su sitio podría estar funcionando y, sin embargo, es posible que sus nombres no se resuelvan si su proveedor externo sufre una interrupción o un DDoS dirigido a uno de sus clientes.
cnst
8

Para mis dominios personales (y los dominios de algunos amigos con los que ayudo), alojamos nuestro propio DNS y mi registrador (Gandi) proporciona un DNS secundario. O un amigo en otra red proporciona secundaria. Gandi no actualiza las zonas de inmediato, parecen verificar aproximadamente una vez cada 24 horas, pero los cambios son muy poco frecuentes; funciona bastante bien para nosotros, y su servidor es probablemente mucho más confiable que el nuestro.

En mi trabajo, hacemos nuestro propio DNS y nuestro proveedor de red ascendente proporciona DNS secundario. Sin embargo, somos una universidad y el 99% de nuestros usuarios están en el sitio; Si la red local está inactiva, no importa si DNS está inactivo. Además, tenemos una clase B completa (/ 16) con aproximadamente 25k registros DNS (más 25k registros DNS inversos, por supuesto), lo que parece un poco incómodo de administrar a través de una interfaz web. Nuestros servidores DNS locales están altamente disponibles y son muy rápidos.

freiheit
fuente
3
Hacemos lo mismo aquí. Tenemos dos cajas de Linux que ejecutan BIND (una pri la otra seg), y nuestro 'ISP' también ejecuta DNS secundario.
l0c0b0x
1
Ídem. También con una clase B, que también ejecuta nuestros propios servidores DNS BIND. Y cuando tenemos problemas de DNS, generalmente es con nuestro sitio
externo
Gran respuesta; Esta es mi respuesta favorita para esta pregunta hasta ahora, porque en realidad se basa tanto en prácticas de ingeniería sólidas como en una estimación realista de la redundancia y disponibilidad disponibles, así como en la experiencia personal; mientras que muchas otras respuestas simplemente enumeran su proveedor de DNS de terceros favorito, o copian ciegamente los escritos escritos por personas con un claro conflicto de intereses de ganar dinero extra con las soluciones de ingeniería excesiva que proponen.
cnst
5

He hecho las dos cosas. Puede haber beneficios con el alojamiento propio: definitivamente aprendes mucho sobre cómo funciona el DNS cuando tu jefe te pregunta por qué lleva tanto tiempo. Además, tienes mucho más control de tus zonas. Esto no siempre es tan poderoso como debería ser, en gran parte debido a la naturaleza jerárquica distribuida del DNS, pero de vez en cuando resulta útil. Doblemente, si puede hacer que su proveedor lo asigne como SOA para el DNS inverso de su bloque de IP, suponiendo que tenga uno.

Sin embargo, todos los comentarios anteriores sobre cómo realmente debería tener una gran resistencia a las fallas incorporada anteriormente son contundentes. Los servidores en diferentes centros de datos en diferentes áreas geográficas son importantes. Habiendo logrado superar el apagón masivo en el Noreste en 2003, todos aprendimos que tener una caja en dos centros de datos diferentes en la misma ciudad, o incluso en una provincia o estado, no es necesariamente suficiente protección. La euforia que se activa cuando se da cuenta de que sus baterías y luego los generadores diesel le salvaron el trasero se reemplaza rápidamente por el temor causado por la constatación de que ahora está manejando con su llanta de repuesto.

Sin embargo, siempre ejecuto nuestro servidor DNS interno para la LAN. Puede ser muy útil tener un control completo sobre el DNS que su red usa internamente, y si se corta la energía en su oficina, su servidor DNS interno en virtud de estar en el bastidor del servidor probablemente esté en batería o batería y diesel, mientras que su PC no lo hará, por lo que sus clientes estarán desconectados mucho antes que el servidor.

Kyle Hodgson
fuente
4

Estoy leyendo todas estas soluciones con cierta diversión porque logramos encajar accidentalmente en todos estos "requisitos" al alojar nuestro DNS primario fuera de una línea DSL estática, y hacer que el registrador (que estaba en otro continente) proporcionara un DNS secundario en un Conexión mucho más seria y confiable. De esta manera, obtenemos toda la flexibilidad de usar bind y establecer todos los registros a la vez que tenemos la seguridad razonable de que el secundario se actualiza para reflejar estos cambios y estará disponible en el caso de que se incendie una alcantarilla, por citar una ocurrencia.

Esto cumple efectivamente:
"Un mínimo de dos servidores DNS autorizados para su dominio";
"Los servidores DNS deben estar conectados a diferentes redes físicas y fuentes de alimentación".
"Los servidores DNS deberían estar en diferentes áreas geográficas".

dlamblin
fuente
Este es ciertamente un enfoque para sentirse bien; pero si se incendia una boca de inspección, y toda su infraestructura se cae, sin DNS, ¿cuál es el punto de que el DNS aún esté disponible, cuando ninguno de los servidores se pudo contactar? :-) Creo que entrar en problemas con el DNS secundario de terceros solo tiene sentido si usted mismo también externaliza otros servicios a otros terceros.
cnst
@cmst El punto es que cuando dns está inactivo, cualquiera que le envíe un correo electrónico, ve un problema inmediato (clientes, socios, muy mala publicidad). Si el dns funciona y el servidor de correo está inactivo durante algunas horas, en su mayoría no se dan cuenta de nada.
kubanczyk
@cmst DNS no se limita a apuntar a servidores en mi red personal. Puedo nombrar IPs en cualquier lugar. Como, tal vez tengo un nombre para cada uno de mis cuadros NAT de la red doméstica de mis empleados / amigos. O podría usar otros tipos de registros e identificar / verificar públicamente algo.
dlamblin
4

Echa un vistazo a Dyn.com ; tienen todo tipo de servicios relacionados con DNS, como alojamiento de DNS, DNS dinámico, MailHop, etc. Los he encontrado confiables y los he estado usando durante probablemente 5 años.

Knox
fuente
2
+1, he usado DynDNS durante aproximadamente 2 años y estoy completamente satisfecho con su servicio.
cdmckay
Dyn.com solía ser dynDNS antes de alrededor de 2013.
Knox
3

Depende.

He ejecutado mi propio DNS para mis diversos trabajos desde finales de los 80 (BSD 4.3c). Para el trabajo, siempre he alojado mi propio DNS, pero siempre he tenido múltiples ubicaciones de centros de datos o he podido intercambiar DNS secundarios con un socio. Por ejemplo, en mi último trabajo hicimos DNS secundario para un .EDU diferente (estaban en MN, estamos en CA), e hicieron lo mismo por nosotros. Diversidad geográfica y de red.

O, en mi trabajo actual, tenemos nuestros propios centros de datos en la costa este y oeste (EE. UU.). Alojar nuestro propio DNS nos permite incluir cualquier registro DNS inusual que podamos necesitar (SVR, TXT, etc.) que podría no ser compatible con algunos de los servicios DNS de la GUI. Y podemos cambiar los TTL cuando lo deseemos; tenemos una flexibilidad máxima, a costa de hacerlo nosotros mismos.

Para cosas de casa, lo he hecho en ambos sentidos. Para algunos dominios donde estoy haciendo cosas inusuales, o necesito mucha flexibilidad, todavía ejecuto mis propios servidores DNS "ocultos" e intercambio servicios DNS públicos con otros que están haciendo lo mismo. Utilizo RCS para controlar la versión de los archivos de zona para la gestión de la configuración, por lo que puedo ver todo el historial de cambios de zona desde el principio de los tiempos. Para cosas simples como un dominio con un solo blog o servidores web genéricos (un registro A o un CNAME), es más fácil usar un servicio DNS de registradores de dominio donde esté disponible y ahora preocuparse por CM.

Es una compensación. El control y la flexibilidad máximos tienen el costo de manejar la diversidad por su cuenta, ejecutar múltiples servidores, lidiar con fallas de hardware / software, etc. Si no necesita la flexibilidad o el control total, cualquiera de los proveedores de DNS de primer nivel resuelva su problema, probablemente a un costo total más bajo.

tep
fuente
Si bien es cierto que es más fácil usar simplemente el DNS del registrador, no es tan raro que el DNS de un registrador esté inactivo, mientras tanto el registro de dominio como su propio host están activos, pero su sitio no está disponible, porque ha agregado un punto de falla adicional a su configuración por razones de facilidad. Realmente no es tan difícil ejecutar su propio DNS; especialmente hoy en día con la gran cantidad de servidores livianos y fáciles de usar.
cnst
3

Como ya se mencionó en este hilo, existen varios casos especiales con DNS, la diferencia más significativa es entre las implementaciones autorizadas y el almacenamiento en caché del servidor de nombres.

  1. Si necesita un servidor DNS solo para resolver los recursos de Internet, una solución inteligente es una resolución DNS gratuita. Yo personalmente uso el recursor PowerDNS (pdns-recursor) en Linux.

  2. Para dar servicio a su infraestructura externa, como sitios web o MX's, no usaría NS internos (si estamos hablando de SOHO aquí). Utilice algún servicio bueno, confiable y a prueba de balas como DNSmadeasy . Utilizo su paquete de negocios, y es genial a la vez que es muy asequible.

Taras Chuhay
fuente
Muchas personas también respaldan la opinión de un DJB de nunca ejecutar un caché de DNS (el resolutor recursivo) en el mismo sistema que un DNS en servicio (el almacenamiento de archivos de zona). Esto es por razones de seguridad, por lo que los agujeros en uno no afectan al otro y viceversa.
kubanczyk
2

He usado Zonedit o años. Es barato (o gratuito) y he agregado muchos registros CNAME, A, MX, TXT, SRV y otros.

Steve Jones
fuente
2

Recientemente trajimos nuestro DNS público en casa cuando trajimos todos nuestros servicios en casa. Esto nos permite actualizar todo tan rápido como sea necesario. Tener un DNS distribuido geográficamente no es un requisito para nosotros en este momento ya que los servidores web están todos en el mismo sitio.

mrdenny
fuente
2
¿Su correo electrónico también está alojado en ese sitio? Tenga en cuenta que si pierde la conectividad allí, y el correo electrónico está fuera de esa red, sus registros MX desaparecerán y el correo electrónico dejará de funcionar incluso si está alojado en otro lugar. Si también está en el mismo sitio, no es gran cosa, pero he visto este argumento desmoronarse por esta razón varias veces en el pasado.
Justin Scott, el
1
Sí, esos tipos están manejando su correo electrónico en el mismo sitio (ya no estoy en esa compañía).
mrdenny 01 de
2

Tengo lo mejor de ambos mundos.

Alojo mi DNS público para mis sitios web y mis registros MX "en otro lugar". Es confiable, es seguro, funciona, puedo modificarlo a voluntad. Pago el servicio y estoy contento con el valor.

Pero en casa, ejecuto mi propio servidor DNS de almacenamiento en caché en lugar de confiar en mi ISP. Mi ISP tiene la costumbre de perder DNS, tener DNS lento, DNS inválido y, a veces, quieren pervertir el DNS para que las fallas lleguen a lugares en los que creen que podría estar interesado. No estoy interesado en usar el DNS de mi ISP. Así que tengo mis propios servidores DNS de almacenamiento en caché y lo hago yo mismo. Fue un poco difícil de configurar al principio (tal vez 2 horas), pero está limpio y tengo un DNS confiable. Una vez al mes, un trabajo cron interroga a los servidores raíz y actualiza la tabla de sugerencias. Tal vez una vez al año tengo que jugar con él, como enviar doubleclick.com a 127.0.0.1 o similar. Aparte de eso, no requiere intervención y funciona muy bien.

codebunny
fuente
El problema con el DNS de terceros es que si está inactivo, incluso si su sitio está activo, las personas no pueden acceder a su dominio. (Esto en cuanto a la redundancia!)
cnst
2

Si decide alojar su propio DNS por amor de Dios, tenga DOS servidores DNS por sitio. Uno para su DNS externo, conectado directamente a su firewall para que el mundo lo encuentre. Y uno separado dentro de su red para su DNS interno.

XTZ
fuente
Esta práctica se llama horizonte dividido. Probablemente, no es aplicable a la mayoría de las configuraciones, francamente, y ha estado bastante desactualizado, fuera de la gran empresa, desde hace bastante tiempo.
cnst
@cnst Split-horizon (o vista dividida) está sirviendo a diferentes zonas bajo el mismo nombre de dominio, y XTZ no dijo que lo recomendara. Un servidor interno generalmente sirve un nombre de dominio diferente (tal vez un subdominio).
kubanczyk
2

Todavía no puedo comentar, pero estoy haciendo lo mismo que freiheit. Ejecutamos nuestro DNS primario aquí en nuestra DMZ, y nuestro ISP tiene varios servidores DNS esclavos en todo el país que se actualizan inmediatamente después de realizar un cambio en el DNS primario.

Da lo mejor de ambos mundos; control inmediato más redunancy.

pauska
fuente
2

Hay ventajas y desventajas en cada enfoque, pero definitivamente estoy a favor de alojar su DNS interno internamente. La lista de cosas de las que depende para los servicios de red básicos si la aloja externamente es alucinante. El CEO podría pensar que es inteligente ahorrar dinero en servidores DNS alojándolos externamente, pero ¿qué pensará cuando no pueda recibir su correo electrónico si el enlace de Internet se cae?

Maximus Minimus
fuente
Gran respuesta, +1! Avance rápido hasta 2017, ¿todavía cree que el DNS interno es el camino a seguir? :-)
cnst
1
@cnst ffwd para 2017 Ya no tengo suficiente experiencia para hacer una recomendación.
Maximus Minimus
2

Por experiencia, si desea atraer un ataque de denegación de servicio, aloje su propio DNS. Y tu propio sitio web.

Creo que hay algunas cosas que no debes hacer tú mismo. El alojamiento DNS es uno de ellos. Como muchas personas han dicho, necesitaría servidores redundantes, conexiones y ubicaciones físicas y aún no se acercaría a la resistencia de las empresas de alojamiento más pequeñas.

El mayor beneficio de alojar su propio DNS es que se pueden hacer cambios de inmediato. ¿Necesita acortar sus TTL para una próxima migración? Probablemente podría escribir un script que lo haga en sus propios servidores; para el DNS alojado, es posible que deba iniciar sesión y cambiar manualmente los registros, o peor aún, llamar al proveedor, pasar por 3 niveles de soporte hasta que finalmente llegue a alguien que pueda deletrear DNS, solo para que le digan que enviarán el Cambios en 2-3 días.

David Oresky
fuente
2

Ejecuto mi propio DNS usando BIND en servidores Linux. Actualmente tengo cuatro ubicados en Londres, Reino Unido, Miami, Florida, San José, CA y Singapur. Funciona muy bien y tengo control total. La estabilidad del centro de datos es muy importante, por lo tanto, he seleccionado buenos DC para ejecutar los servidores (no dependientes del ISP o alguna otra infraestructura 'desconocida'). Puedo configurar servidores DNS y otros servicios en cualquier parte del mundo utilizando los DC de clase mundial que selecciono en función de criterios estrictos. El DNS sólido es esencial para los servicios web y de correo electrónico que ejecuto.

Justin Jones
fuente
LOL, excelente pieza publicitaria, ¿puedo obtener el número de su departamento de marketing y su editor? Estoy marcando como un candidato obvio para el correo no deseado, pero al mismo tiempo no me sorprenderé si esta bandera también se rechaza.
Cnst
2

¿Deberíamos alojar nuestros propios servidores de nombres?

Sí, y también debe usar uno o más de los grandes proveedores de DNS de terceros. Es probable que una solución híbrida sea el enfoque más seguro a largo plazo por varias razones, especialmente si es una empresa que tiene una gran cantidad de SLA o requisitos contractuales para sus clientes. Más aún si eres b2b.

Si sus servidores DNS maestros (ocultos o públicos) son su fuente de verdad, entonces usted se protege operacionalmente de quedar atrapado en las capacidades específicas del proveedor. Una vez que comience a usar sus ingeniosas funciones que van más allá del DNS básico, puede encontrar que cambiar a otro proveedor o alojar su propio DNS es problemático, ya que ahora tiene que replicar esas capacidades. Ejemplos serían las comprobaciones del estado del sitio y la conmutación por error de DNS que proporcionan Dyn y UltraDNS. Esas características son geniales, pero deben considerarse únicas y no una dependencia. Estas características tampoco se replican bien de un proveedor a otro.

Si solo tiene proveedores de terceros, su tiempo de actividad puede verse afectado cuando están bajo un ataque DDoS dirigido. Si solo tiene sus propios servidores DNS, su tiempo de actividad puede verse afectado cuando es el blanco de un ataque DDoS.

Si tiene uno o más proveedores DNS y sus propios servidores DNS distribuidos que son esclavos de los servidores DNS maestros ocultos que controla, se asegurará de que no esté encerrado en un proveedor en particular y de que mantenga el control de sus zonas en todo momento. Los ataques deben derribar tanto a sus servidores como a uno o más proveedores importantes que esclavan sus servidores. Cualquier cosa menos que eso será una degradación del servicio frente a una interrupción crítica.

Otra ventaja de tener sus propios servidores maestros (idealmente ocultos, inéditos) es que puede crear su propia API y actualizarlos en cualquier mansión que se adapte a las necesidades de su negocio. Con proveedores de DNS de terceros, deberá adaptarse a su API. Cada vendedor tiene el suyo; o en algunos casos, solo tiene una interfaz de usuario web.

Además, si su maestro está bajo su control y un proveedor tiene un problema, cualquiera de sus servidores esclavos que aún puedan comunicarse con su maestro recibirá las actualizaciones. Esto es algo que desearía tener después de darse cuenta de que tener un tercero como su maestro fue un error durante un gran incidente de DDoS y no puede cambiar ninguno de los servidores de los proveedores que no están bajo ataque.

Desde una perspectiva legal, evitar el bloqueo de proveedores también puede ser importante para su negocio. Por ejemplo, Dyn está siendo potencialmente comprado por Oracle. Esto los coloca en una posición única para recopilar estadísticas de DNS de todos los clientes de Dyn. Hay aspectos competitivos de esto que pueden introducir riesgos legales. Dicho esto, no soy abogado, por lo que debe consultar a sus equipos legales y de relaciones públicas al respecto.

Hay muchos otros aspectos de este tema si quisiéramos profundizar en las malezas.

[Editar] Si esto es solo para un pequeño dominio personal / hobby, entonces 2 máquinas virtuales que no están en el mismo centro de datos entre sí, ejecutar un pequeño demonio DNS es más que suficiente. Lo hago para mis propios dominios personales. No estaba claro para mí si su dominio significaba un negocio o solo por hobby. Cualquiera que sea la VM más pequeña que pueda obtener es más que suficiente. Yo uso rbldnsd para mis dominios; usando un TTL muy alto en mis registros, ya que ocupa 900 KB de RAM y puede manejar cualquier abuso que la gente le arroje.

Aaron
fuente
Si bien es demasiado centrado en la empresa, esta es una buena respuesta razonable, ¿podría alguien que dio el -1 explicar por favor?
cnst
Dos buenos puntos nuevos sobre la API y las fusiones de proveedores. Dos DC están bien, pero también tenga en cuenta que tiene un ISP separado para cada uno, no el mismo ISP.
kubanczyk
Buen punto @kubanczyk muiltiple ingresa enlaces para una conmutación por error segura y automatizada y controles de estado en ellos.
Aaron
1

Piense en el alojamiento de DNS como la base de sus servicios públicos. En mi caso, el correo electrónico es fundamental para nuestro negocio. Si aloja su DNS internamente y su conexión a Internet falla, sus registros DNS pueden volverse obsoletos, lo que obliga a que su dominio no esté disponible.

Entonces, en mi caso, si no se puede encontrar un registro MX para nuestro dominio, el correo electrónico se rechaza de inmediato.

Entonces, tengo nuestro DNS alojado externamente.

Si el registro MX está disponible, pero nuestra conexión a Internet no funciona, el correo continuará haciendo cola en los servidores que intentan enviar correos electrónicos a nuestro dominio.

Brian
fuente
No creo que esto sea cierto en lo que respecta a los MXregistros; de hecho, es una de las ideas falsas documentadas en cr.yp.to/djbdns/third-party.html .
cnst
0

Depende. ™

He estado ejecutando mis propios servidores y administrando dominios desde al menos 2002.

A menudo he usado el servidor DNS de mi proveedor.

El número de veces que mi servidor en mi IP estaba disponible, pero mi DNS no, era demasiado.

Aquí están mis historias de guerra:

  • Un proveedor de yuge en Moscú (uno de los primeros basados ​​en VZ) tenía mi VPS en un DC de "valor" barato, pero su DNS estaba en un DC de última generación con tráfico costoso, en dos diferentes / 24 subredes, como lo requerían algunos TLD en ese momento . En un momento dado, un desastre (¿posiblemente el apagón de 2005? ), Y su costosa DC se desconectó, y mi sitio (todavía en Moscú, pero en una DC de "valor") solo podía accederse por su dirección IP.

    Curiosamente, incluso antes de cualquier incidente, recuerdo claramente haberlo hecho traceroutey, al notar el mismo DC para ambos ns1y ns2para mi ISP, les pedí que también trasladaran uno a "mi" DC, por geo-redundancia; Desestimaron la idea de la redundancia geográfica, porque los servidores ya estaban en el DC más premium posible.

  • He tenido otro proveedor (uno de los primeros basados ​​en el sistema ISP), donde tenían uno en el sitio y otro en el extranjero. En pocas palabras, toda la configuración fue ridículamente defectuosa, y el servidor "en el extranjero" a menudo no pudo mantener sus zonas, por lo tanto, mi dominio efectivamente tenía un punto extra de falla y no sería accesible incluso si todo mi servidor aún funcionaba sin problemas.

  • He tenido un registrador que maneja su propia red. Se caía de vez en cuando, a pesar de que mis servidores externos estaban activos. Mi DNS estaba caído.

  • Recientemente he usado múltiples proveedores de grandes nubes para secundaria, donde yo mismo dirijo un maestro oculto. Ambos proveedores cambiaron su configuración al menos una vez; nunca con anuncios públicos; Algunos de mis dominios dejaron de resolverse. También le pasó a un amigo mío, con uno de los mismos proveedores. Esto sucede más a menudo con servicios de terceros que las personas que desean admitir en público.

En resumen, http://cr.yp.to/djbdns/third-party.html es absolutamente correcto en el tema.

Los costos de tener que molestarse con DNS de terceros a menudo no valen los beneficios.

Los aspectos negativos de tener un DNS de terceros a menudo se pasan por alto injustamente.

Diría que a menos que su dominio ya use servicios de terceros (por ejemplo, para web, correo, voz o texto), agregar un DNS de terceros casi siempre sería contraproducente, y de ninguna manera es la mejor práctica en todas las circunstancias. .

cnst
fuente