Siempre me he preguntado cómo está diseñada la infraestructura DNS para (digamos, un TLD .com). No sólo debe ser capaz de mantener un alto nivel de confiabilidad, sino también admitir grandes cantidades de actualizaciones de los registros en tiempo real.
Supongo que BIND de ISC se utiliza en ese nivel. Tengo una idea bastante clara de cómo alguien construiría una infraestructura escalable usando BIND. La parte que no tengo clara es cómo alguien diseñaría un sistema que pueda manejar la adición, eliminación y cambio de cientos de zonas DNS cada pocos segundos. Hay innumerables registradores de dominios en el mundo y .com por sí solo probablemente genere una enorme cantidad de actividad. ¿Cómo se adapta un sistema basado en archivos de zona BIND a tantos cambios?
¿Tengo razón al dudar de que un operador de TLD utilice archivos de texto y haga que BIND recargue constantemente los cambios cada vez que se registra un nuevo .com? Si es así ¿qué hacen? ¿Está respaldada por una base de datos SQL o LDAP? ¿Eso incluso escala?
Respuesta1
En primer lugar, ¿realmente crees que hay más actualizaciones que, digamos, transacciones con tarjeta de crédito por segundo en el mundo, gestionadas finalmente por sólo 2 o 3 empresas? Esos funcionan, por lo que es un problema que tiene solución :-)
En segundo lugar, es posible que se sienta confundido acerca de cómo se realizan las actualizaciones, porque es una parte poco comprendida donde se cruzan dos planos: el plano de registro y el plano de publicación. Es posible que también se sienta confundido por lo que sucede exactamente en los servidores de nombres de registro (solo se mantienen los NSregistros para las delegaciones de dominios, y NO el contenido completo de esas zonas).
Pero antes de entrar en eso, también parece asumir que las actualizaciones deben realizarse en tiempo real, donde no son necesarias y, a menudo, no lo son. De todos modos, nada es en tiempo real en el DNS, debido al TTL.
Así que volvamos a tus dos aviones:
- los registradores envían actualizaciones a los registros, cuando cambian los servidores de nombres y otras operaciones que tienen efectos secundarios de DNS (por ejemplo, configurar
clientHoldel estado de EPP); este es el plano de registro, no tiene ninguna correlación con la publicación DNS y normalmente utiliza un protocolo llamado EPP; cuando el registro responde "actualización aceptada", no significa en absoluto que ya esté publicada en su infraestructura DNS, es solo una garantía de que "lo estará en algún momento". - Los registros mantienen el plano de publicación DNS, asegurándose de que sus servidores de nombres publiquen los
NSregistros correctos para todas las delegaciones, es decir, todos los dominios registrados bajo los TLD que administran.
Como tal, el número de cambios probablemente sea mucho menor de lo que usted tiene en mente: si un .compropietario cambia el contenido de su zona, con nuevos registros, en la mayoría de los casos, no hay nada que hacer a través del registrador y nada cambia en el registro autorizado. servidores de nombres.
Y esos cambios NO ocurren a través del mecanismo de actualización de DNS. Los registradores impulsan los cambios utilizando un protocolo específico, EPP, los cambios se almacenan de alguna manera en alguna base de datos del registro, después de lo cual el registro publica los nuevos datos en sus servidores de nombres autorizados.
También parece pensar que el "tiempo real" es obligatorio. No lo es, al menos no técnicamente, y puede que incluso por un diseño ineficaz (considere si quiere hacer pruebas de que los nuevos cambios tienen sentido, como lo están haciendo algunos registros comprobando que los servidores de nombres estén configurados correctamente para la resolución del nombre). pronto aparecerán como autorizados para pruebas DNSSEC, por ejemplo...).
Una forma típica de configuración, utilizada por muchos registros que proporcionan cosas como un "retraso de 10 minutos para las actualizaciones" o "1 hora", es almacenar en algún búfer interno todos los cambios solicitados en ese período de tiempo determinado y luego de una vez por todas. genere la nueva zona y publíquela, mientras inicia un nuevo búfer para recopilar todos los cambios que se producirán en el próximo período.
Supongo que BIND de ISC se utiliza en ese nivel.
De nada. Verisign ejecuta su propio software de servidores de nombres, llamado Atlas. ver por ejemplohttps://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html Tenga en cuenta que en este artículo de 2004 ya se dice:
VeriSign Naming and Directory Services (VNDS) promete actualizar los 13 servidores de nombres autorizados principales .com y .net en menos de cinco minutos. La tasa actual es de aproximadamente dos veces por día.
Por supuesto que mejora desde entonces. Pero creo que incluso una vez cada 5 minutos es suficiente para cualquier uso práctico real del DNS.
También podría haber obligaciones contractuales, y específicamente para los registros y registradores de gTLD que están bajo contrato con la ICANN. El contrato actual Verisign-ICANN está enhttps://www.icann.org/en/registry-agreements/details/com Puede encontrarlo en §6.6 del apéndice enhttps://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-enDetalles sobre las restricciones de actualización:
6.6 Frecuencia de actualización. El Operador de Registro realiza actualizaciones oportunas de los datos de los servidores de nombres DNS y Whois. Los registradores acreditados por ICANN registran estas actualizaciones a través del SRS. Luego, el SRS actualiza el servidor de nombres DNS y el Whois. El Operador de Registro procesa estas actualizaciones casi en tiempo real.
La especificación de rendimiento comprometida con respecto a la frecuencia de actualización tanto para el servidor de nombres DNS como para el Whois es de 3 minutos para el 95% de las transacciones durante un período de tiempo mensual. Es decir, el 95% de las actualizaciones de los servidores de nombres DNS y Whois durante un período mensual se completarán en 3 minutos. La frecuencia de actualización se mide desde el momento en que el Operador de Registro confirma la actualización hasta el momento en que la actualización aparece en el Servidor de nombres DNS y Whois. El desempeño de la frecuencia de actualización se informará mensualmente a la ICANN de acuerdo con el Apéndice 4.
Tenga en cuenta la marca habitual de "95%" que se utiliza para muchos SLA. Por lo tanto, es casi en tiempo real cuando es posible, pero en la práctica suele ser de 3 minutos (de ahí la configuración típica del búfer descrita anteriormente).
Tengo una idea bastante clara de cómo alguien construiría una infraestructura escalable usando BIND. La parte que no tengo clara es cómo alguien diseñaría un sistema que pueda manejar la adición, eliminación y cambio de cientos de zonas DNS cada pocos segundos.
Verisign tiene sólo un par de zonas: .com, .net, algunos IDN, etc. No gestionan "cientos de zonas". Y ciertamente no cientos de ellos con muchos cambios cada segundo.
Es posible que desee o desee estar más interesado en los proveedores de DNS que alojan millones de zonas con una posible alta frecuencia de actualizaciones. Aquí hay un artículo de CloudFlare donde explican lo que hacen en cuanto al rendimiento con respecto a su servicio DNS autorizado:https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/
Hay innumerables registradores de dominios en el mundo.
No, no todo. Lejos de ser innumerables. De hecho, menos de 2000, y probablemente sólo unos 500 realmente activos con grandes volúmenes de cambios. Todos los registradores de gTLD deben estar acreditados por ICANN. Puedes encontrar la lista completa de ellos enhttps://www.icann.org/en/accredited-registrars
¿Tengo razón al dudar de que un operador de TLD utilice archivos de texto y haga que BIND recargue constantemente los cambios cada vez que se registra un nuevo .com?
Ningún software de servidor de nombres de alto nivel de transacciones estaría respaldado por archivos de texto. Incluso Bind no lo es: cuando las actualizaciones dinámicas están habilitadas, tienes un archivo de "diario" (que es binario) y específicamente no debes editar la versión del archivo de texto de la zona (sin congelar primero las actualizaciones y luego permitirlas nuevamente después de la editar).
Si es así ¿qué hacen? ¿Está respaldada por una base de datos SQL o LDAP? ¿Eso incluso escala?
Dudo que SQL o LDAP sean buenos motores de almacenamiento para DNS. Recuerde que el DNS es de naturaleza jerárquica, lo que plantea varias limitaciones.
Respuesta2
En primer lugar, en algunos casos no es necesario recargar inmediatamente.
Si tiene un SLA que dice "páguenos y registrará su dominio dentro de X horas", incluso podría recargarlo periódicamente usando algún trabajo cron o similar. Por lo tanto, es posible que algunos registradores utilicen archivos planos y los recarguen periódicamente.
Tenga en cuenta que podría tener varios servidores DNS asociados a la misma dirección IP (por ejemplo, usando anycast), por lo que incluso podría configurar un mecanismo de "implementación continua", que cambia el archivo plano en todas partes y recarga un servidor DNS a la vez. tiempo.
Dicho esto, Bind >9 admite DLZ (Zonas cargables dinámicamente), lo que esencialmente permite a Bind usar una base de datos como backend de datos de zona. Las bases de datos (y las conexiones de bases de datos) se pueden escalar de acuerdo con las estrategias clásicas de escalado de bases de datos, siempre que tenga un controlador DLZ válido para su base de datos.
Finalmente, como dijo un comentario, el escalado vertical (es decir, tener mucha CPU, RAM e IOPS para cada servidor) ayuda.
Hay un 2009SANOGPuede que la diapositiva te resulte interesante, aunque evidentemente está un poco desactualizada:https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf