General

NIC Ecuador y la importancia de la infraestructura DNS

Hace dos años escribí en este blog un post sobre NIC Venezuela, y las dificultades operativas que estaba atravesando en momentos de cambio de la estructura burocrática que la opera. Hoy, una falla en los servidores raíz del ccTLD .ve ocasionó una caída del servicio DNS y por consiguiente, que por alrededor de tres horas la vasta mayoría de personas dentro y fuera de Venezuela no pudieran acceder a los 217 mil dominios venezolanos, con el consiguiente impacto político y económico.

Así que quedó claro, de una forma un poco dolorosa, la fragilidad que tienen las infraestructuras DNS de algunos ccTLD, y el impacto que tiene DNS en la operación de un país. Ahora bien, ¿es posible extrapolar la situación de NIC Venezuela a la del NIC del Ecuador? Considerando que la motivación de mi post entonces fue, principalmente, entender cómo podríamos superar a la burocratización de esa entidad, que es pública, cuando en Ecuador el nic.ec es operado por una empresa privada, parecería que no hay mucho que extrapolar. Pero hagamos el ejercicio.

¿Qué pasa cuando usted escribe http://www.<algo>.ec?

Este nombre debe ser traducido a una dirección IPv4 o IPv6. Una dirección IPv4, por ejemplo, puede verse como 154.65.43.2, y una IPv6 como 2801:0:60::1. Pero esto es irrelevante para el usuario pues la conversión se hace detrás de las cámaras. Además, los resultados de estas conversiones se guardan en una memoria temporal (caché de DNS) ya sea en su máquina, en su router Wi-Fi o inclusive en los servidores de su ISP. De hecho, normalmente su ISP es el responsable de hacer esta conversión, pero cuando la dirección que usted solicita termina en .ec, incluso su ISP deberá consultar a NIC Ecuador para poder darle una respuesta.

El ccTLD ecuatoriano (.ec) es servido por cuatro servidores DNS. Dos de ellos, n1.nic.ec y n2.nic.ec, están asignados al mismo sistema autónomo, y presumiblemente, están en el mismo sitio físico (muy probablemente, en un centro de datos en las oficinas de NIC Ecuador, en el Edificio La Previsora del Malecón en Guayaquil) lo cual como mencioné en mi artículo de NIC Venezuela, puede ser un problema por razones de seguridad física y resiliencia ante desastres. Claro que, lo mismo ocurre con los DNS de algunos ISP, pero estos no son autoritativos para la zona .ec.

Por supuesto, n1 y n2 no son los únicos. Los otros dos servidores están fuera de Ecuador. El primero es operado por ISC, una organización inteacional, y el segundo es una adición reciente, n3.dns.ec, que no me queda muy claro quien lo está operando, pero está en la Costa Oeste de los Estados Unidos. Dos servidores, n2.nic.ec y n3.dns.ec, también responden por IPv6. Esto nos da una ventaja adicional en caso de problemas con IPv4 o de un escenario solo-IPv6, pero aun es marginal.

Replicación en el exterior y sistema de registro

Cuando se maneja un esquema así, la aplicación de registro (el sistema de NIC Ecuador) que se encarga de interactuar con los usuarios que son dueños de un dominio .ec, y escribir los resultados de sus solicitudes a los servidores, también debe replicar estos nuevos cambios a los servidores alteos.

Es de esperar que la aplicación de registro escriba primero en n1.nic.ec y n2.nic.ec, ya que están muy probablemente en sus oficinas, pero debe escribirse también a los servidores alteos. Como observación preliminar, hay momentos en que n1 y n2 responden con un serial de zona más actualizado que los otros dos. Quizás que la replicación no es inmediata.

Esto podría significar que, de existir algún problema en Guayaquil, los alteos tendrían información vieja, y se podrían perder las actualizaciones, o que se presente un escenario como el de la replicación de la zona corrupta que ocurrió en el .ve, al menos para roughly la mitad de los clientes DNS.

Update: hay momentos del día en que hay sincronización, y ventanas en que no siempre ocurre. Hice algunas observaciones más y conseguí que el tema es consistente con los dos servidores exteos en algunas horas del día. Aquí hice otras en el cambio del serial del 29 al 30 de mayo, aun más interesantesEsto es relativamente normal en operaciones de ccTLD, con ciclos de 15 minutos, aunque en estas observaciones hay ciclos mayores. Pero podría ser un problema del lado de los operadores de esos servidores exteos, y además, ¿podrían reducirse esos tiempos?

Conclusiones

No tengo ninguna razón para pensar que en NIC Ecuador puedan presentarse problemas como el que ocasionó la caída de hoy en Venezuela, pero tampoco tengo evidencia para pensar lo contrario, así que pensemos en ese escenario en el que la zona quede vacía, se replique a los alteos, eventualmente a los servidores de los ISP, y todas las consultas a dominios terminados en .ec no devuelvan respuesta lo que dejaría por ejemplo al .gob.ec fuera de operación hasta que se resuelva el problema. El impacto sería muy alto, y, sobre todo con el advenimiento de IPv6 (del cual ya existe regulación al respecto emanada del MINTEL) se vuelve total y absolutamente imprescindible.

Tratando de aprender de los dos mundos, de las cosas que se han hecho bien en los NIC de ambos países, podría sugerir que se promueva la instalación de réplicas en universidades, y en los centros de datos de los ISPs a través de la AEPROVI. Ecuador opera un NAP exitosamente, pero podría tomarse la idea de los grandes proveedores como Google o Microsoft que facilitan servidores preinstalados y preconfigurados con valor agregado para los operadores. Por ejemplo, una imagen de un sistema operativo Linux que opere un servidor DNS, un servidor NTP, un relay Teredo, un exit point de Tor… no sé, algo que ofrezca valor agregado. Si se firma un convenio para tener a alguien pendiente 24/7, y luego de un período de prueba y monitorización, ese servidor DNS podría entrar como una réplica. En este escenario “altamente distribuido”, la operación se volvería más compleja, sí, pero aumenta la resiliencia del modelo.

(Por cierto, tener un NAP en Venezuela no hubiera necesariamente impedido que se presentara el problema de hoy.)

Y, por supuesto, operar un par de servidores DNS adicionales afuera de Ecuador también representaría una gran ventaja. Técnicamente, no sería operar pues en algunos casos los convenios solo permiten que se haga la copia y no operarlos per se, pero los beneficios son importantes.

Pero aquí otra idea: ¿por qué NIC Venezuela no hospeda una copia de NIC Ecuador y NIC Ecuador una copia de NIC Venezuela
? Conozco a los administradores de sistema de ambos NIC, y tienen una buena comunicación, ¡podría ser una buena idea!

Creo que el aprendizaje es importante. DNS se encuentra en la capa más fundamental de la infraestructura de Inteet, y en medio de un escenario de crecimiento en el acceso a Inteet, especialmente de banda ancha, y de mayor acceso a servicios de gobieo electrónico, una falla en el servicio DNS en Ecuador o en cualquier otro ccTLD resultaría en pérdidas económicas y de confianza en el sistema. Y aunque suene a exageración nerd, no tenemos una infraestructura DNS infalible.

Mis más cordiales saludos a todos los que se dedican a mantener estas infraestructuras fundacionales de Inteet funcionando, en Venezuela, en Ecuador y en donde sea. Funcionamos gracias a ustedes.
Standard

4 thoughts on “NIC Ecuador y la importancia de la infraestructura DNS

  1. calu says:

    Excelente enfoque técnico de nic.ec en cuanto a su infraestructura de DNS. Pero dos de las quejas más grandes son: a) costos elevados de registro de dominios .ec, y b) poco o nulo valor agregado, simplemente se registran y nada mas (ausencia de API’s, registro de NS propios, registro de MX, A, CNAME propios, etc.)

  2. phenobarbital says:

    Saludos Bureado! …Si, tengo entendido por el propio Eduardo Mendez que se estaban haciendo gestiones para que ISC tuviera una copia y además para que la copia Chilena fuera una copia operativa, sin embargo, también es una culpa de CANTV, que siendo el mayor ISP, no hace copia de ninguna de las zonas, incluso de dominios que están en sus datacenters (salvo algunos dominios delegados, como cantv.com.ve) y al fallar los NIC venezolanos, falla la resolución de los DNS de CANTV, las copias de zona (con un TTL más alto) de Movistar y Digitel permitieron a mucha gente navegar por páginas .ve por más horas.-btw tengo entendido que Eduardo está en la reunión de LACNIC allá en Ecuador?Saludos!

  3. Anonymous says:

    Jesús, efectivamente, quien puede actuar más rápido ahora es CANTV, y las empresas del Estado como CORPOELEC (en EDELCA se dedicó un Sun Sunfire para esto, pero no se llegó a operar) o PDVSA en la medida que tengan sus propios AS (o si no sería lo mismo que depender de un ISP privado o de CANTV) y siendo sinceros, solo se necesita compromiso. Operar una copia de DNS para una empresa como CANTV debería ser trivial.En cuanto a los convenios inteacionales, con ISC hay una copia ahora (ns-ext.isc.org) pero se podrían tener otras entiendo que con ICANN, pero hay unos temas burocráticos en la firma de esos convenios.El LACNIC XVII fue hace unas tres semanas, Eduardo estuvo por acá, yo participé en LACSEC pero tuve la oportunidad de acompañarlo en el BOF de operadores de ccTLD, no son problemas aislados de Venezuela, por cierto. Pero hay que pensar en el futuro a la vez que se asegura lo que ya está, IPv6, DNSSEC, etc.

  4. Juan Angulo Moreno says:

    Hola José,Una de las soluciones que se debería manejar en Venezuela (y en cualquier otro lugar del mundo) es tener en cada ISP dentro del país (caso CANTV/Movistar/Digitel/Comsat/GlobalCrossing/Inter/Etc) una copia de la raíz del ccTLD vía Anycast DNS, es buena/bonita/barata y podría ser el comienzo para la creación de un NAP en el país. Recuerdo que ese proyecto lo estuvo manejando el amigo Joaquin Muñoz pero ya el no está en NIC.VE.Un abrazo!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s