Category Archives: DNS

Nuestro docker no resuelve DNS

hoy mientras instalaba un nuevo docker en CentOS-8 me topé por segunda ocasión que el contenedor no resolvía nombres de domino.

Cuando intentaba realizar alguna operación dentro del contenedor que requería resolver un nombre me devolvía error de que no podía resolver.

Por ejemplo, el contenedor era de CentOS, y cuando intentaba instalar un paquete (yum install….) me devolvía:

Cannot find a valid baseurl for repo: base/7/x86_64

Pero, puede ocurrir con cualquier otro comando (apt, dnf, ping, wget, curl, etc).

Para validar que efectivamente era un problema de mi servidor y no del contenedor en específico probé un docker muy sencillo “busybox” que tiene el conocido comando ping:

docker run --rm busybox ping -c 1 8.8.8.8
...
64 bytes from 8.8.8.8: seq=0 ttl=116 time=18.972 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

Como se puede ver, hace perfectamente ping desde un contenedor hacia 8.8.8.8

Ahora probaré lo mismo pero con un nombre, para que se vea obligado a resolver

docker run --rm busybox ping -c 1 www.google.com
ping: bad address 'www.google.com'

¡Efectivamente falla! no puede resolver una dirección.

Esto se debe a que en el firewall de nuestro CentOS-8 no se están permitiendo la resolución de nombres. Agrego la interfaz docker0 a la lista de interfaces confiables:

sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0
sudo firewall-cmd --reload

Y ahora pruebo:

docker run --rm busybox ping -c 1 www.google.com
PING www.google.com (172.217.170.4): 56 data bytes
64 bytes from 172.217.170.4: seq=0 ttl=116 time=18.897 ms
--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 18.897/18.897/18.897 ms

Trabajó al 100% luego de esto!

nauta.cu no navega bien, por qué rebotan los mensajes

Actualización 20141001: Indiqué del problema a ETECSA y este fue corregido minutos después.

Adelantándome un poquito en el tiempo quiero indicar que este problema está ocurriendo en Setiembre del 2014, no quiere decir que este será un problema a futuro, quizá lo corrijan. Si usted tiene un problema con nauta.cu, mejor contácteles a ellos.

Rebotes de correos dirigidos a nauta.cu

El día de hoy un amigo me comentó que continuamente los correos que enviaba a su familia en Cuba le rebotaban, que a veces no rebotaban, pero otras veces sí. Leí un mensaje rebotado y decía algo relacionado con los DNS: que no podía resolver el dominio en los DNS.

Inicialmente pensé que podría ser una falla en el servicio por inundación de peticiones (DoS) sin embargo ahora en la noche me pongo a analizar los dns definidos por nauta. Son aparentemente 5:

ns1.etecsa.net, ns2.etecsa.net, ns3.etecsa.net, ns4.etecsa.net y ns5.etecsa.net

El sitio http://www.squish.net/dnscheck/ realiza un chequeo transversal de DNS, verificando la misma pregunta (query) que se le indique en todos los DNS definidos para un dominio (en este caso sería de ns1 a ns5.etecsa.net).

Procedí  a usarle para verificar los records MX definidos para el dominio nauta.cu notando que de 2 de estos 5 DNS fallan directamente indicando que no hay records MX. Es decir, 2/5, un 40% de las peticiones que se realizan a los DNS de nauta.cu para averiguar su record MX falla indicándose que tal record no existe.

DNS de nauta.cu fallando
DNS de nauta.cu fallando

Por lo tanto cualquier servidor de correos que tenga la mala suerte de preguntarle a estos DNS que fallan (ns2 y ns4 al momento) recibirá mensajes indicando que no hay MX, que no hay servidor de correos, y los correos posiblemente reboten sin llegar a su destinatario.

nauta.cu has no MX record!

Por qué ocurre esto?

Los DNS normalmente trabajan en un modelo que se llama de maestro-esclavo (o primario-secundario) mediante el cual uno de los DNS es el maestro, donde se realizan las adiciones/modificaciones/eliminaciones de records de una zona. Los DNS esclavos son el resto y los esclavos simplemente se ocupan de incorporar las modificaciones que existan en el maestro sean incorporadas a ellos. De esta forma se garantiza que un cambio en el maestro se vea reflejado en todos los esclavos.

Si ETECSA tuviera sus 5 DNS en formato 1 maestro->4 esclavos esto no sucedería pues al modificarse el maestro, los esclavos tuvieran la misma información. De esta forma las respuestas de todos los DNS fueran las mismas (bien o mal, pero las mismas).

Por qué entonces en nauta.cu 3 DNS sí entregan el record MX de la zona y en los otros 2 DNS no? Porque no están completamente configurados en modo maestro-esclavo. Entonces el administrador de los DNS debe realizar los cambios no en un sólo DNS (el maestro) sino en varios o todos; y lógicamente puede olvidarse de modificar uno o varios de los DNS como aparenta ser el caso.

Cómo se soluciona? En principio al menos el administrador de los dns debe agregar el record MX a todos los DNS, en la forma que estén utilizando, sea multiples master o maestro-esclavo o lo que sea. Y luego por facilidad debería cambiar los dns a un formato maestro-esclavo para que no vuelva a suceder esto.

Además los 5 dns de nauta.cu (ns1 a ns5.etecsa.net) tienen punto de falla en común. Qué es esto? Significa que los DNS en cuestión están localizados en la misma red. Esto es fácil de ver en la siguiente imagen:

Punto de falla en comun en dns de etecsa
Punto de falla en comun en dns de etecsa

Como podemos observar de ns1 a ns4 están evidentemente en la misma red y en el AS27725. Y ns5 está aparentemente en una red diferente, pero en el mismo AS (AS27725). Una falla en algún ruteador, sobrecarga, inundación de paquetes, pérdida de paquetes, etc, que ocurra en un equipo clave de la etecsa conllevaría a que todos los DNS dejen de responder y los correos reboten. Si al menos tuvieran un DNS fuera de su red, esto evitaría el punto de falla en común por lo que siempre alguien respondería a las peticiones que se hagan a sus dominios.

Hay más temitas, pero que los arregle el responsable de esa zona.

ddclient to update dns-o-matic

install ddclient package.

Edit /etc/ddclient.conf

An at the end add this:

##
## DNS-O-Matic account-configuration
##
use=web, web=myip.dnsomatic.com
server=updates.dnsomatic.com, \
protocol=dyndns2, \
login=username, \
password=password    \
all.dnsomatic.com

Of course login and password must be changed to suite your own ones.

Imágenes de ayer, nuevamente defacement y ataques a sitios del gobierno, estado y personas públicas de Ecuador.

 

Ayer dediqué una parte de la mañana (y de la tarde) a monitorear en unas pocas redes sociales (twitter, facebook), y con la ayuda de buscadores los sitios del gobierno de Ecuador que iban cayendo presas de sus, muchas veces simples o triviales, fallas de seguridad.

El motivo de este ataque, esta vez, fue una protesta de parte de personas que se denominan Anonymous contra un reglamento de telecomunicaciones que contiene muchos elementos que deberían mejorarse enormemente.

A propósito de este ataque: el año pasado cercano a esta fecha del 10 de Agosto igualmente ocurrió una protesta en la cual se atacaron por diversos métodos sitios del gobierno y estado Ecuatoriano. Cuando ocurre aquel ataque medité (wow, qué palabras más… bueno)… y escribí aproximadamente por estas fechas aquí.

“Guerra avisada no mata soldado” dice una vieja frase. Este tema ya había ocurrido el año pasado y pumpum, coge de nuevo, exactamente un año después, vuelven los ataques. Y no digamos un año después, estos ataques han venido ocurriendo con relativa frecuencia durante el año anterior y los años anteriores.

Recuerdo que el año pasado se anunció que se estaba trabajando con un grupo de expertos coreanos en seguridad, creo recordar lo dijo alguien del ramo, quizá de algún ministerio y se generaron varios comentarios en los medios noticiosos.

Y sin embargo, volvimos a recaer, a pasar por exactamente lo mismo. Y sobre las medidas tomadas por motivo de lo ocurrido el año pasado (no medidas coercitivas sino medidas de protección y aseguramiento)…. nadie ha sabido, quizá se olvidó, pasó al olvido como muchos temas van pasando al olvido a medida que el tiempo pasa.

En un artículo aparte hablaré más del tema, en este me referiré solamente a mostrar las páginas que logré capturar defaceadas (algunas incluso hoy 11 de Agosto las capturé, es decir: los responsables al parecer ni se han enterado de que les han cambiado su página o andan ocupado en temas más trascendentes que no les alcanza la oportunidad para todavía quitar el defaceo).

Vamos, que yo estaba con la idea de ayer dedicar parte de la mañana a preparar una simple antena para hacer algunos experimentos cuando tuve la idea de entrar a facebook, donde encontré a algunos amigos mencionando sobre sitios del gobierno. Recuerdo que lo primero que les comenté a ellos fue:

“pero cuál es la idea? porque sitios .ec hackean todos los días http://www.zone-h.org/ o es que hay un rally o algo así hoy? o es por el día 10 de agosto?”

Si te fijas a medida que voy escribiendo me voy dando cuenta que tiene relación con la fecha… porque en realidad yo consideraba esto de ataques en fechas patrias (10 de Agosto) algo del pasado, algo resuelto porque sucedió ya el año pasado! Y ya se habló y se dijo mucho sobre eso, y ya habían expertos apoyando en esto no? Sí o no?!!!!!

Es que me ofende mucho que se vuelva a caer en temas que con un poco de razonamiento no puedan se solucionados. Y si no conocen, por qué no buscan una verdadera asesoría? no hay que llegar a presentar un proyecto en el senescyt para lograr cierta seguridad en las redes.

Bueno, veamos el primero que veo reportado:

Continue reading Imágenes de ayer, nuevamente defacement y ataques a sitios del gobierno, estado y personas públicas de Ecuador.

Ya implementamos IPv6 en los dns de nuestrodns.com

Bueno, me faltaba este detalle, pero por fin hoy me decidí ya atacarlo y por fin ya tenemos IPv6 en los servidores de nuestrodns.com

así que ya tengo dominado la implementación de ipv6 en los servicios más necesarios para Linux.

gov.ec -> gob.ec 98% ? Estás seguro?

Este post es una continuación del que publiqué en setiembre del 2010 que decía mi opinión sobre el cambio de gov.ec a gob.ec y repito, me parece excelente la idea pero los tiempos y la planificación y la orientación me parecen pocos y en ciertos casos nulos.

Es increíble, en el sitio del mintel.gob.ec dice que hay un nivel de “aceptación” del 98%. Qué es aceptación? Cómo se puede medir este indicador? Digo, si es un indicador!.

Bueno, me dediqué a mirar solamente en DOS sitios.. solamente dos pues pienso que los demás igual o peor estarán. En los dos sitios relacionados con las telecomunicaciones en el país.

1- En la página del senatel  –  conatel

2- En la propia página del mintel!

Y en ambos casos el cambio de gov.ec a gob.ec no ha sido completado!! Esto NO ESTA BIEN

Mira:

El mejor es el del mintel, mira al final de la página como tienen puesto el mail con su nombre de dominio anterior y no sólo eso, sino que en el código fuente tienen referencias al .gov.ec viejo:

Te fijas abajito como dice [email protected] ? NI ELLOS MISMOS HAN MIGRADO CORRECTAMENTE!

Veamos el código fuente de esta misma página:

98% de aceptación? Por favor pongamos indicadores que sean medibles.. qué significa 98% de aceptación? Yo podría definir aceptación como “cambio realizado” y la página de ellos mismos no está cambiada… así que acaso serán el 2% restantes? En todo caso sería vergonzoso que no tengan el cambio realizado.

Veamos ahora conatel – senatel:

Fíjate como en esta página el enlace a la presidencia (mira abajo al final de la imagen a la izquierda) sigue siendo al sitio viejo!! Increíble! La misma página que repite la noticia del mintel de que hay un 98% de aceptación!

Y bueno, ya que estoy en el tema, me fui a la página de la asambleanacional.gob.ec y veamos el código fuente:

No te convence? Bueno, veamos dos más! Uno muy simple:

El sitio www.presidencia.gob.ec está casi bien.. pero vete al enlace que dice: discursos – intervenciones, te lleva a una página llamada elciudadano.gov.ec sí con V !! Y además mira elciudadano.gob.ec déjale el mouse arriba de cada enlace, aparecen los enlaces con el nombre del sitio viejo, .gov.ec!!!

Mira acá abajo a la izquierda, ves como dice www.elciudadano.gov.ec el enlace sobre el que estoy? Es increíble!

Y este, es el mejor, la subsecretaría de informática del gobieno, no se han molestado en cambiarse, cómo te va? No me crees? Entra a www.informatica.gob.ec y mira TODOS los enlaces apuntan a .gov.ec en vez de a .gob.ec, mira:

Fíjate igualmente aquí abajo… ves como dice www.informatica.gov.ec ? Esto es en todos los enlaces!

Resumo algo: Estas imágenes acaban de ser tomadas hoy 5 de Enero del 2011, 5 días después del límite para el cambio. Las tomé sin escoger, tomé simplemente varios sitios del gobierno representativos (esto del ciudadano.gob.ec me salió por la presidencia.gob.ec). Y a todos los anteriores sitios entré por sunombre.gob.ec (es decir por su nuevo nombre de dominio), sin embargo siguen apuntando a su viejo nombre.

Es por eso que sigo pensando que el cambio debe ser dilatado un poco más.. y está bien que nic.ec no haya eliminado los .gov.ec porque sino el problema sería gigantesco por estos días.

Y realmente me preocupa que simplemente digan 98% de aceptación algo que claramente ha sido mal cambiado en muchos sitios por lo que simplemente veo.

Por qué no hubo un proceso de asesoría como les sugerí? Por qué no dilatan un poco más el tiempo de vida de los viejos dominios? Por qué muchos por qués?

Como siempre, a sus órdenes.

Mi opinión sobre el cambio de .gov.ec a .gob.ec

Primero que todo, parto diciendo que la decisión de cambiar a la v por la b en los dominios .gov.ec a .gob.ec me parece buena, correcta. Pero sin embargo preveo dificultades dado el poquísimo tiempo dado para el cambio.

Es decir, pienso que el periodo dado para el cambio (hasta finales del año 2010), algo así como unos 6 meses traerá algunas dificultades.

Vamos a comenzar por las más fáciles:

  1. Habrá que reconfigurar en los DNS los nuevos dominios. Afortunadamente es un proceso bastante automático y afortunadamente nic.ec ha agregado automáticamente todos los .gob.ec de los .gov.ec que actualmente existen. Lo ha hecho apuntando a los dns del .gov.ec de forma tal que el dueño de ese dns puede reconfigurar (agregar la zona) ese dns. Es bien simple pero espero que algunas personas todavía no le hayan hecho ni le hagan en el futuro.
  2. Habrá que agregar aliases al servidor web para que funcione el nuevo y el viejo dominio. Es agregar un serveraliases. Es simple y lo deben hacer los administradores de los servidores web. Aunque pensándole bien yo preferiría que se hiciera un redirect hacia el nuevo sitio para que ya los buscadores se vayan enterando de los nuevos nombres. Es importantísimo y será ignorado.
  3. Habrá que agregar aliases al servidor de correos para que funcione el nuevo servidor de correos. Es un tema bien fácil y lo deben realizar los administradores de los servidores de correo partiendo que ya cumplieron con el punto 1.

Ahora, el problema es que si piensas hasta aquí, todo va bien, sin embargo veamos unos temas que lamentablemente pasarán y ya son más complejos, los pondré en orden de menos complejos a más complejos.

  1. Habrá que reconfigurar algunos sitios que tienen hardcoded el nombre del sitio, por ejemplo al referirse a un enlace algunos administradores no usan /enlace.html sino http://www.sitio.gov.ec/enlace.html al dejar de funcionar el .gov.ec habrán bastantes fallos. Claro que es un error de concepto, de creación y particularmente yo exigiría a los programadores de los sitios que le hagan bien.
  2. Hay un caso similar al anterior y es en los manejadores de contenido, hay que reconfigurarle para que ya no haga referencia al .gov.ec sino al .gob.ec esto por ejemplo en el joomla creo que se define en un config.php simplemente. Pero lamentablemente muchos ignorarán este paso y sólo se darán cuenta del problema al momento que deje de funcionar el anterior sitio.
  3. Habrá que comprar un nuevo certificado SSL para los sitios que le usen. Esto no tiene solución es decir, hay que hacerlo.. tenemos varios casos de dominios del gobierno ecuatoriano que usan SSL.. ahora al eliminarse el viejo nombre, habrá que adquirir un certificado para el nuevo sitio pues los SSL se otorgan por nombre del sitio y al cambiar esto se toma como un nuevo sitio.
  4. Habrá que esperar que los buscadores de internet tomen en cuenta los nuevos sitios. Esto será complejo muchos buscadores seguirán refiriéndose al viejo sitio durante meses o más. Sugiero por eso que se hagan redirects desde ahora del viejo nombre al nuevo nombre para que los buscadores vayan acostumbrándose al nuevo sitio desde ahora.
  5. Muchos sitios tienen enlaces (links) a los sitios del gobierno ecuatoriano, estos enlaces se perderán. Esto sí tomará años posiblemente y se perderán muchos enlaces que daban importancia a ciertos sitios, pues ya no existirán enlaces válidos.. esto sí será penoso.

Yo sugiero algunas cosas:

  • Que se designe una comisión que defina los parámetros correctos para la migración de la forma más rápida posible
  • Que esta comisión asesore a los organismos del gobierno con los problemas más comunes
  • Que se extienda el periodo de migración al menos por un año.. no por 6 meses.

Es importante extender el periodo, de lo contrario habrán problemas antes mencionados de forma más grave.

El presidente de Estados Unidos puede cerrar comunicaciones por internet hasta por 120 días

Si aprueban el “kill switch” el presidente de Estados Unidos podría ordenar a uno o varios proveedores a que tomen medidas para evitar amenazas a la seguridad de Estados Unidos.

Esta acta que posiblemente aprueba pronto, contiene un lenguaje muy abierto que en resumen da la opción al presidente americano en funciones a ordenar un cierre temporal hasta por 120 días de las conexiones de internet de uno o varios proveedores.

Es una medida más drástica que la que actualmente pueden tomar de acuerdo al Acta de Comunicación.. y no sólo por drástica debemos tenerla en cuenta, sino porque a la final la historia siempre se repite.

Un poco de historia:

La mayoría de los estados siempre han tenido leyes o disposiciones que les permiten a sus gobiernos en caso de grave conmoción nacional o estado de guerra a limitar o cerrar sus comunicaciones. Se conoce como “silencio de radio” por ejemplo aquí en Ecuador se aplicó en el último conflicto con el Perú en los años noventa. Los radioaficionados son ordenados a vigilar ciertas zonas del espectro y reportar cualquier comunicación que hallen sospechosa. No se puede emitir excepto por radios comerciales o gubernamentales bajo estrictas medidas de segurida (incluso se puede llegar a silenciar totalmente estas radios).

Ahora piensa: qué pasaría si hicieran lo mismo en internet? Supón que a los cibernautas les impidan entrar a los servidores de China o de Estados Unidos.. te parece gracioso? pues podría ser posible.

Supón que no pudieras entrar temporalmente a google o a tu sitio preferido de noticias o de espectáculos. Pero más aún:

  1. ten en cuenta que Estados Unidos es el hub de las comunicaciones por internet. Para tu llegar desde X país a Y país, casi siempre, casi casi siempre tienes que pasar por Estados Unidos.
  2. Los DNS son manejados en muchos casos en el territorio americano, si se suspendiera este servicio para uno o varios países, estos países pasarían mucho trabajo comunicándose.
  3. Los nombres de dominio, muchas personas los adquieren en Estados Unidos…allá ellos!

En resumen, yo creo que hay que tomar medidas inmediatas para independizar sus contenidos de estas posibles acciones. Y lo gracioso es que notamos que pocos gobiernos son los que hacen esto.

La internet está cambiando, y va a cambiar…

Creando zonas en BIND (named)

Partiendo del hecho de que tenemos instalado el named.conf de aqui, entonces podemos seguir estos ejemplos para crear un DNS de zona master o un esclavo:

Maestro

El siguiente ejemplo es para un supuesto dominio llamado: dominio.com en rojo remarcamos el ejemplo. En el caso de que usted haya adquirido un dominio, debe sustituir el nombre en rojo del ejemplo por su propio dominio.

Al final de /etc/named.conf agregar:

zone "dominio.com" IN {
 type master;
 file "/var/named/dominio.com.hosts";
 allow-update { none; };
 // Esto es solo si tenemos un esclavo
 allow-transfer { 192.168.0.101; };
 also-notify { 192.168.0.101; };
};

En /var/named/chroot/var/named/dominio.com.hosts

$ttl 7200

dominio.com. IN SOA localhost.localdomain. mi.email.com. (
 2008010701
 10800 ; Tiempo de refrescamiento
 3600 ; Tiempo de reintento si falla el refresh
 604800 ; Tiempo para mantener los esclavos su info si no contactan al master
 7200 ) ; TTL

dominio.com. IN NS localhost.localdomain
www IN A 192.168.0.89
mail IN A 192.168.0.89
ftp IN A 192.168.0.89
dominio.com. IN MX 5 mail.dominio.com.
dominio.com. IN A 192.168.0.89

Activar el servicio de named:

service named start
chkconfig named on

Cada cambio que se realice en el named requiere que recarguemos (reload) o reiniciemos (restart) el named.

Esclavo:

En /etc/named.conf agregar:

zone "dominio.com" IN {
 type slave;
 file "slaves/dominio.com.zone";
 // Esta es la IP del master
 masters { 192.168.0.89; };
};

Activar el servicio de named:

service named start
chkconfig named on