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?

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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

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.

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