Vuestro compañero Daniel Navarro, propone esta entrada para comentar en el blog:
Tenemos un servidor que da un servicio web (por ejemplo apache). Los dominios y los contextos del servidor se van añadiendo de forma automática a través de un formulario de alta para los clientes, el cual añade a la configuración DNS la entrada correspondiente al dominio dado de alta y a su vez añade en la configuración del servidor web el contexto para que pueda servir este dominio. Ejemplo: Cliente: prueba Dominio: prueba.misblogs.com Entrada en el DNS: =prueba:X.X.X.X:300 Contexto de apache: ServerName prueba.misblogs.com El problema que se plantea es que desde que un cliente se da de alta hasta que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que utilice este cliente que actualizar la zona. ¿Se podría hacer alguna configuración en la cual no hiciese falta actualizar el DNS cuando se diese de alta un nuevo cliente?
19 replies on “DNS + Blogs”
Para resolver este problema lo que hay que hacer es reinicializar la base de datos de nuestro servidor de nombres para que tenga en cuenta el nuevo dominio añadido.
Para realizar esto, podemos añadir un pequeño script que se encargue de recargar la configuración de bind al dar de alta un nuevo domino. Bastaría tan solo con añadir una orden similar a kill -HUP `pidof named`.
Con esto conseguiríamos cargar el nuevo dominio sin necesidad de parar y levantar todo el servidor DNS.
Al menos esto es lo que yo he entendido de la pregunta.
Esta parte no me ha quedado muy clara:
El problema que se plantea es que desde que un cliente se da de alta hasta
que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que
utilice este cliente que actualizar la zona.
En teoria los DNS que tu pongas en el cliente no afectan, ya que los subdominos que agregues se va a encargar tu servidor DNS de administrarlos , y este es el único que debe actualizarse, los DNS que tengas por encima no influyen ya que no les compete administrar tu dominio. Ellos simplemente preguntarán a tu servidor donde esta ese “prueba.misblogs.com”.
Saludos
Hola Carlos.
Aunque esa es una opción totalmente valida, yo estaba pensando en otras ya que aunque sobre el papel la propagación de una dns depende solo del ttl que tu configures (que suele ser alto), la realidad es que muchos servidores DNS tardan un tiempo en venir a preguntar (ya sea por malas configuraciones o por problemas de conexión o saturación de red). Por otro lado tendríamos el inconveniente de tener que estar recompilando la BD cada vez que se da de alta un cliente, si lo pusieses en un sitio tipo blogspot o algo así que seguro que da de alta mas de 100 usuarios hora, a la BD se le “encolarian” las recompilaciones, sin hablar de lo “inmanejable” que debe ser un fichero de DNS con millones de entradas.
Lo que yo busco es una configuración del DNS con la que no haga falta recompilar la BD (ni tocar la configuración) cada vez que de de alta a un nuevo cliente.
Un Saludo.
Bueno, yo creo que lo que pides no puede hacerse. Es decir, para que DNS te conteste, debe tener en algún lugar que el nombre XXXXXX corresponde a la IP A.B.C.D. Si el DNS no tiene eso no va a poder contestarte. Apache no debería encargarse de rectificar la información que el servidor DNS esta dando, de hecho la petición jamás debería llegar a Apache si el servidor DNS no sabe que ese blog es de su dominio. Desconozco si Apache tiene alguna directiva que corrija la información del servidor DNS, pero a mi juicio sería mezclar cosas y entrariamos en el “intrusionismo laboral” que tan de moda está ahora :D.
El tema que dices de “recompilar” la BD realmente no es así (que yo sepa la BD no se compila, de hecho creo que ni si quiera se cambia el formato de la BD como puede ocurrir con /etc/passwd en los *BSD). Añadir un nuevo dominio puede ser tan sencillo como un echo “bla bla bla” >> db.mi_domino, y para cargarla con el kill -HUP `pidof named` o similar. Esta operación puede tardar segundos en realizarse, no hay encolado de peticiones salvo que los 1000 usuarios se den de alta en el mismo instante. Y si esto ocurre te tienes que preocupar de si tu servidor soporta esa carga, y si la soporta pues nada, uno detrás de otro.
Por el tema que comentas de un servidor DNS con millones de entradas, esto solo tendría sentido en un blog grande, y estos sitios tienen recursos suficientes para tener varios servidores DNS cada uno administrando un grupo de subdominios (por ejemplo por orden alfabetico) o algo similar. O incluso dentro del mismo servidor partir la configuración en trozos pequeños para ser mas manejable.
EL campo TTL voy a leer sobre el porque no tengo muy claro realmente como funciona. En las pruebas que hice tengo el campo TTL a 3 horas y el cambio se hizo de forma “instantánea”. Me imagino que será un campo más enfocado a “dominios de primer orden” que a subdominios dentro de otro dominio que ya existe. Es decir, si yo tengo carlos.blogs.ua y añado otro que se llame daniel.blogs.ua, este cambio debería ser gestionado por el servidor de blogs.ua. Pero si tenemos carlos.nuestrosblogs.blogs.ua y añadimos daniel.nuestrosblogs.blogs.ua, como todos esos cambios son gestionados por el servidor que nosotros administramos (nuestrosblogs.blogs.ua), el añadir o borrar carlos.nuestros….. o daniel.nuestros…. es inmediato. El servidor blogs.ua manda la petición a nuestrosblogs.blogs.ua y el sí sabe que tiene una nueva máquina que se llama daniel.
La solución que puse en el post anterior la he probado en un entorno casero, y el tiempo de respuesta de activar/desactivar un subdominio era de menos de 2 segundos.
Por cierto, una herramienta para la gestión del servidor desde linea de comandos y que se puede usar en scripts es rndc. Con esta herramienta puedes cambiar opciones, recargar la BBDD, etc
http://swoolley.org/man.cgi/rndc
#3 Si te das cuenta, en blogs.ua.es no pasa ya que eligieron distinguir por el recurso local (es decir, blogs del estilo blogs.ua.es/airc) 😉
Sobre el TTL, tened en cuenta que afecta al tiempo que se guarda el dato en la Caché de los servidores DNS (http://en.wikipedia.org/wiki/Time_to_live). Según esto, qué pasaría en esta circunstancia:
1.- Servidor DNS del dominio EPS.UA.ES hace un cambio en el nombre del equipo http://www.eps.ua.es El TTL es de 3 horas
2.- Servidor DNS caché de Telefónica (por ejemplo) tiene la entrada http://www.eps.ua.es desde hace 2 horas 58 minutos.
¿Cuándo llega la actualización a los clientes de Telefónica? ¿Cuándo llega la actualización a los clientes del servidor del dominio EPS.UA.ES?
Por lo demás, buena discusión pero me gustaría que en vuestras argumentaciones usaráis referencias a documentación externa (libros, artículos, URLs,…)
Me ha faltado una pregunta sobre ¿cuándo llega la actualización a los clientes?
He preguntado por los clientes de telefónica, los del servidor del dominio, pero ¿y el resto?
No os desviéis del tema de la entrada. Las preguntas las he puesto para que reflexionéis (en privado 😉 ) por las pruebas que Carlos comenta en #3 que ha realizado y los resultados que indica.
Solo una puntualización sobre el campo TTL, Por lo que puedo ver, el campo TTL afecta a nombres/dominios YA existentes y que por cualquier motivo cambian o desaparecen.
Por lo tanto, en nuestro tema de añadir blogs el campo TTL no afectaría en nada, ya que son nombres nuevos. Podria verse influenciado a la hora de modificar/borrar un blog ya existente, pero para solucionar ese problema podríamos obligar a esperar un tiempo determinado para realizar cambios sobre un blog ya creado.
Si esto es así, es normal que mis pruebas fuesen inmediatas, ya que los dominios con los que probé eran nuevos y por lo tanto al no existir anteriormente no quedan guardados en ninguna caché.
Saludos.
PD: La documentación que estoy mirando es la oficial de bind ( http://www.bind9.net/manuals ) y el libro DNS & BIND, 5 edicion de O’Reilly
#7 Exacto. Afecta a lo que está guardado en caché y, por tanto, lo nuevo no puede estar; pero siguiendo con matices, la difusión NO es inmediata: falta que pregunte un cliente por ella.
Seguid con el tema de la entrada.
Buenas.
Como Carlos dice en mi entrada hay puntos de fallo de seguridad, lógicamente, ya que es un supuesto para un ejemplo. Lo que intento es poner un ejemplo ilustrativo.
Para continuar con el tema y no seguir con la discusión, vamos a decir que hay una opción a nivel de configuración de DNS, que es lo que estamos tratando aquí, que es mas óptimo que la opción que ha expuesto el compañero Carlos.
Un Saludo.
Buenas,
#9 Cuando dices vamos a decir que hay una opción… es que estas haciendo una suposición?
Lo digo porque que yo sepa y que haya mirado, no he encontrado una opción que el DNS haga que cualquier cadena perteneciente a un subdominio la tome como válida. Esto no tendria ningun sentido, existiria el blog carlos.misblogs.es pero tambien afdsafaser.misblogs.es el cual (salvo que alguien lo haya dado de alta) no existe en ningún sitio.
Repito, CREO que lo que tu quieres hacer o planteas no es posible. En algún lugar debe haber algo que te diga que carlos.misblogs.es pertenece a la IP A.B.C.D, y ese lugar debe ser por definición el servidor DNS.
En cuanto al tema de rendimiento he hecho esta noche unas pruebas. Me he creado un cutrescript y he añadido 1 000 000 de subdominios para ver que tal funcionaba y no se notan pérdidas de rendimiento. En cuanto el subdominio estaba creado, éste se hacía visible al momento (el servidor casero es de un amigo en Galicia, para no realizar pruebas en local, ya que en local va todo más rapido). Este es el script que he usado para crear los dominos:
#!/usr/local/bin/bash
BBDD=donde_sea.txt # Base de datos
IP=la_que_sea # Direccion IP del servidor
NUM_DOM=1000000 # Numero de subdominios
for ((i = 0 ; i > $BBDD # Añado el dominio a la base de datos
kill -HUP `pidof named` # Recargo la base de datos
done
Este script simula la creacion de un subdominio y la recarga al final de cada subdominio creado. Recargar la BBDD después de añadir el millon de subdominios también es inmediato.
Y esta la máquina que hacía de servidor:
OS: Linux 2.6.31.6-vs2.3.0.36.24/i686 – CPU: AMD Athlon(tm) XP 1700+ (1460.516 MHz) – Processes: 86 – Uptime: 1d 3h 24m – Load Average: 0.04 – Memory Usage: 231.87mb/758.01mb (30.59%) – Disk Usage: 23.94gb/93.76gb (25.53%)
Como se puede ver no estamos hablando de ninguna maquina quadcore con 32 GB de ram. Es una maquina sencillita y puede realizar el trabajo de resolver todos esos subdominios sin apenas pérdidas de tiempo/rendimiento.
Saludos
Ha pasteado mal el script. Aqui dejo lo que use, cambia el bucle del for
#!/usr/local/bin/bash
BBDD=donde_sea.txt # Base de datos
IP=la_que_sea # Direccion IP del servidor
NUM_DOM=1000000 # Numero de subdominios
for ((i = 0 ; i > $BBDD # Añado el dominio a la base de datos
kill -HUP `pidof named` # Recargo la base de datos
done
Vale, no lo pega bien. En este enlace está el script. Si se puede borrar el post anterior que se borre.
http://pastebin.com/m5e4bb003
Bien, despues de investigar un poco y preguntar creo que he dado con la solución al problema que planteas.
seria añadir los famosos WILDCARDS a la configuración (el famoso ‘*’).
Con esto añadiendo una entrada del tipo
*.misblogs.es IN A direccion_IP
sería los virtualhost de apache los que gestionasen la configuración de los distintos subdominios
Saludos
PD: Agradecimientos especiales a qat por la ayuda y a goa por el server
Hola Carlos.
Te has currado la solución un huevo, para la próxima, ten claro que si no conociese la respuesta no hubiese hecho la pregunta.
Por otro lado y para que el post puede seguir teniendo discusión, planteo una modificación:
Supongamos que ahora todos los dominios de los clientes van a ser del tipo:
clienteXXXX.misblogs.com donde XXXX es el ID del cliente con la restrcción de que X es alfanumérico.
EJ: cliente1234.misblogs.com o clienteasdf.misblogs.com
Pero no: cliente123.misblogs.com o cliente12345.misblogs.com
PD. Carlos, supongo que para ti esto ya es trivial (no es muy diferente de lo anterior), por lo que mejor dejamos al resto de compañeros intentarlo.
Un Saludo.
jajajaja ok, yo pensaba que pusiste la pregunta porque era una duda que te había surgido y lo planteaste como pregunta.
Sabiendo que sí era posible, me hubiese centrado más en encontrar la solución partiendo desde la configuración de las DNS que intentando dar soluciones alternativas. Estaba cegado en que no era posible y estaba buscando siempre soluciones por otro lado.
Saludos
No estoy muy puesta en esto del DNS lo único que me he dado cuenta es que cuando hemos realizado la practica del servicio DNS es que hay que cambiarlo cada dos por tres para que funcione de todas formas me informare más cuando tenga un poquito de tiempo y entrare de nuevo a dar una opinion mas objetiva, porque de momento no tengo suficientes argumentos como para decir si hay una solucion o no.
Por lo que he visto comentado de mis compañeros Carlos y Dani la verdad es que han llegado a la conclusion de que si hay solucion. Asi que investigare haber si hay una solucion mas optima que la que dan aunque es un poco dificil porque lo han dicho casi todo ya… : )
Saludos
No sé si entiendo muy bien el problema, ya que estoy un poco como Lorena. Pero he estado leyendo en otros sitios y he encontrado que se puede actualizar el DNS utilizando ciertos programas, como Web-DNS. Veo que Carlos y Dani ya ofrecen una solución que parece buena, pero ya digo, sin un esquemita me cuesta ver estas cosas un poco. También recuerdo por la práctica, que el servidor DNS era un poco un engorro. ¿Sería una buena solución lo del Web-DNS? Habría que configurarlo a mano, pero una vez configurado, ya debería estar listo para funcionar ^^
Creo que si se puede hacer, creo que la solución estaría en enviarle una petición al DNS en la que se le hiciera creer que la información que le enviamos es cierta, y hacer que el propio servidor nos cachee nuestra solicitud, con esto conseguiriamos que la información cacheada por el servidor DNS sea servida a los clientes de dicho servidor.
Creo que definitivamente la solución sería alterar o modificar la cache DNS con los nuevos datos, y al mimo tiempo modificar las entradas en el DNS para que el cambio sea definitivo.
De echo, cuando escuchamos noticias como estas, tenemos que saber que estamos ante situaciones similares.
http://blog.elinformatico.eu/2010/02/los-autodenominados-ciber-ejercito.html