Zone Edit y su nueva política
Hasta hace un tiempo venía utilizando Zone Edit para los DNS de los distintos dominios que administro. Hace aproximadamente un mes atrás recibí un mail de dicha empresa anunciando cambios en su servicio e informando que modificarían la política de 5 zonas gratuitas a sólo 2 por cuenta. Lo malo de esto es que dicho cambio se aplicaría a nuevos usuarios pero también a los usuarios existentes, perjudicando a los que ya utilizábamos el servicio. La manera de mantener las 5 zonas era comprando un crédito.
Dado que no me gustó que cambiaran las reglas de uso del servicio para todos lo que ya hacía tiempo que lo estábamos usando empecé, en aquel momento, a migrar algunos de los dominios que administraba a otro servicio, particularmente Free DNS.
En el día de hoy recibí otro mail anunciando que el cambio comenzaría a partir del próximo 27 de agosto, siendo el extracto que dejo a continuación parte del mail que enviaron:
The new ZoneEdit is nearly here! We’re still extending our offer to free customers to purchase a credit and maintain all 5 free zones rather than being reduced to 2 in the new system, so if you intend to purchase a credit and keep your free zones, make sure you do so this week by logging into your account and going to the “Account Info” tab to make a payment. Once your account is migrated, you won’t be able to retroactively purchase a credit to keep 5 free zones.
Por tal motivo, en el día de hoy terminé de migrar el resto de los dominios a Free DNS e hice también el trámite en NIC. Entre los dominios afectados se encuentra el de NetStorming. No obstante no debería haber ninguna caída del servicio y estimo que estará funcionando con los nuevos servidores de DNS en las próximas horas.
Ahora bien, todos aquellos que utilicen Zone Edit tengan precaución con este cambio, dado que no sé cuál será el criterio de la gente de Zone Edit para decidir qué zonas dejan de publicar.
Directiva $GENERATE en Bind
Bind tiene una interesante extensión que permite crear múltiples entradas de forma automática con una única línea. Se trata de la directiva $GENERATE. Supongamos que necesitamos crear los siguientes registros para nuestro DNS reverso:
2 IN PTR host192-168-0-2.netstorming.com.ar. 3 IN PTR host192-168-0-3.netstorming.com.ar. 4 IN PTR host192-168-0-4.netstorming.com.ar. 5 IN PTR host192-168-0-5.netstorming.com.ar. 6 IN PTR host192-168-0-6.netstorming.com.ar. ... 253 IN PTR host192-168-0-253.netstorming.com.ar. 254 IN PTR host192-168-0-254.netstorming.com.ar.
La forma de hacerlo manualmente es escribir cada entrada en el archivo del DNS reverso de BIND. Con la directiva GENERATE esta tarea es mucho más sencilla de realizar y simplifica mucho el mantenimiento del DNS. Simplemente basta con agregar la siguiente línea en lugar de todas las anteriores:
$GENERATE 2-254 $ PTR host192-168-0-$.netstorming.com.ar.
Google Public DNS
Google ha puesto a disposición del público en general dos servidores DNS para que puedan ser utilizados desde cualquier lado. Según ellos, la ventaja de utilizar sus servidores es lograr una mejor velocidad de navegación y mayor seguridad. Los servidores en cuestión tienen las IPs 8.8.8.8 y 8.8.4.4. Para utilizarlos sólo basta con configurarlos de la manera tradicional.
Para obtener mayores detalles de las ventajas del servicio de Google es posible consultar la explicación en Google Code.
Registros de un servidor DNS
Es sabido que los servidores DNS son fundamentales para el funcionamiento de Internet dado que proveen mucha información indispensable. Básicamente, lo que hace un servidor DNS es, dado un nombre, devolver una IP. Pero también son capaces de responder otro tipo de preguntas, como por ejemplo el servidor de mail de un dominio, el de DNS; incluso pueden hacer el trabajo inverso, dada una IP devolver su nombre.
A continuación voy a explicar los registros básicos que utiliza el servicio de DNS, para qué sirven y cómo pueden consultarse. No voy a explicar en este post el funcionamiento de un servidor de este tipo, aunque sí lo haré más adelante.
Registros del DNS
En la tabla anterior se resumen los registros más importantes. Ahora les voy a mostrar cómo hacer para consultarlos para un dominio dado. Para ello me voy a valer del comando dig de Unix. Si lo ejecutan en su computadora verán que la salida es más extensa que lo siguiente; el motivo es que la resumí para hacerla más legible.
Primero preguntaremos la dirección IP del servidor web de NetStorming. Para ello:
sh-3.2# dig www.netstorming.com.ar
;; QUESTION SECTION:
;www.netstorming.com.ar. IN A
;; ANSWER SECTION:
www.netstorming.com.ar. 5168 IN A 200.58.114.40
El comando dig sin parámetros le pregunta al servidor de DNS que tiene configurada la máquina por el registro A del nombre dado. Se ve en la salida del mismo que precisamente eso hizo, obteniendo como respuesta la IP del servidor web de NetStorming. Ahora bien, si desearamos saber el servidor de mail de NetStorming deberíamos especificarle a dig que pregunte por el registro MX para el dominio netstorming.com.ar. Esto se hace de la siguiente manera:
sh-3.2# dig -t mx netstorming.com.ar
;; QUESTION SECTION:
;netstorming.com.ar. IN MX
;; ANSWER SECTION:
netstorming.com.ar. 7200 IN MX 5 netstorming.com.ar.
netstorming.com.ar. 7200 IN MX 0 mail.netstorming.com.ar.
El resultado que se ve es que NetStorming tiene dos servidores de mail que son mail.netstorming.com.ar y netstorming.com.ar. El primero de ellos tiene mayor prioridad (de allí el 0). En este caso, en realidad, si consultan por la IP para cada uno de los dos servidores de mail anteriores verán que es el mismo equipo, pero podrían existir varios.
Ahora bien, algo más que puede hacerse con dig es preguntarle a un servidor específico. Por defecto, dig le pregunta al servidor que tenemos configurado en nuestra máquina. Pero en muchos casos es útil preguntarle a otro servidor. Vamos entonces primero a obtener los servidores de DNS para Google y luego le preguntaremos directamente a uno de ellos por la IP de la página del buscador.
sh-3.2# dig -t ns google.com.ar
;; QUESTION SECTION:
;google.com.ar. IN NS
;; ANSWER SECTION:
google.com.ar. 43200 IN NS ns3.google.com.
google.com.ar. 43200 IN NS ns1.google.com.
google.com.ar. 43200 IN NS ns4.google.com.
google.com.ar. 43200 IN NS ns2.google.com.
En lo anterior, al preguntar por los DNS de google.com.ar obtuvimos cuatro servidores. Ahora vamos a elegir uno de ellos y le vamos a preguntar por la IP de www.google.com.ar.
sh-3.2# dig @ns3.google.com www.google.com.ar
;; QUESTION SECTION:
;www.google.com.ar. IN A
;; ANSWER SECTION:
www.google.com.ar. 86400 IN CNAME www.google.com.
www.google.com. 604800 IN CNAME www.l.google.com.
;; AUTHORITY SECTION:
l.google.com. 86400 IN NS f.l.google.com.
l.google.com. 86400 IN NS a.l.google.com.
l.google.com. 86400 IN NS g.l.google.com.
l.google.com. 86400 IN NS d.l.google.com.
l.google.com. 86400 IN NS b.l.google.com.
l.google.com. 86400 IN NS e.l.google.com.
;; ADDITIONAL SECTION:
f.l.google.com. 86400 IN A 72.14.203.9
a.l.google.com. 86400 IN A 74.125.53.9
g.l.google.com. 86400 IN A 74.125.95.9
d.l.google.com. 86400 IN A 74.125.77.9
b.l.google.com. 86400 IN A 74.125.45.9
e.l.google.com. 86400 IN A 209.85.137.9
En el comando anterior se vio el agregado de “@servidorDNS”. Lo que indica precisamente es que la consulta de “www.google.com.ar” se la haga a ese servidor de DNS. También podríamos haber especificado una IP directamente.
Pero bien, con respecto a la salida probablemente noten algo que les llame la atención. Nosotros preguntamos por un único nombre pero nos devolvió varios servidores diferentes. Esto ocurre porque Google utiliza balanceo de carga en sus servidores web para soportar todo el tráfico que recibe.
Antes de terminar quería mencionarles dos herramientas más que pueden usar con este mismo fin: una es el comando host de Unix que es más simple pero se encuentra en cualquier distribución; el otro es nslookup, que no sólo lo encontrarán en los Unix sino también en Windows.
Ahora sí, es todo. Los invito a probar un poco con distintos dominios y a intentar entender un poco más las salidas y lógicamente pueden comentar si tienen alguna duda o algo que acotar.
Importante bug en BIND
Se ha detectado un bug en el servicio de DNS BIND que posibilita un ataque de DoS en todos los servidores configurados como maestros que ejecuten la versión 9 del software. La vulnerabilidad ha sido calificada como alta por el Internet Software Consortium que da detalles acerca de la misma y altamente crítica por el arcert. La recomendación es actualizar a las nuevas versiones listadas en el reporte del ISC. Se espera que las distribuciones de Linux más populares publiquen los binarias con el parche a la brevedad.
