DNS: Haciendo las cosas bien

Del artículo anterior ([Linux DNS]) y de los recientes acontecimientos de ataques a páginas web, me doy a la tarea de escribir algunos consejos que podrían ser útiles a algunos administradores de DNS, ciertamente no soy un experto en DNS, pero viendo algunos “fallos” en la configuración de algunos DNS oficiales, pues quisiera ayudar un poquito en la enseñanza.

Hace un par de días atrás, una caída masiva en los servidores “.gob.ve” me llevó a hacer algunas revisiones, que llevaron a este artículo (y a la queja de: ¿cómo es eso que los servidores web del SIBCI, VTV, VIVE y otros medios públicos están configurados en redundancia, pero organismos importantes como PRESIDENCIA.GOB.VE, SAIME o SENIAT, no lo están?, ¿qué es más importante para nosotros?), espero sea tomado como una ayuda a entender algunas cosas en las que se está fallando.

El problema

Estaba revisando la definición de algunas zonas, por ejemplo, sirvase a visitar este análisis simple de la zona DNS del SENIAT:

http://www.intodns.com/seniat.gov.ve

Y observe los fallos y advertencias allí nombrados (situación semejante se repite en DNS como SAREN o SAIME), el propio DNS de la empresa CANTV (cantv.com.ve) reporta que su “hostname” es > dns1.cantv.net.cantv.com.ve (de hecho, parece ser que todo DNS gubernamental *parqueado* en CANTV.NET sufre los mismos defectos, son una plantilla de “copy&paste”), tambien podemos revisar los del CNTI:

http://www.intodns.com/cnti.gob.ve

Para otro tipo de fallas, que ya explicaremos más adelante.

Explicando lo básico de una Zona

Veamos una zona básica, extraída del ejemplo anterior:

;
; coopera.net
;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1.coopera.net. IN A 144.76.25.227
dns2.coopera.net. IN A 144.76.25.228
; puntero de la zona
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
        IN      HINFO   VM-XEN "Debian Wheezy 7.0"
; puntero de intercambio de correo
        IN      MX      5    correo.coopera.net.
correo IN A 144.76.25.229
; informacion del administrador de la zona
       IN      RP      jesuslara
jesuslara IN TXT        "Jesus Lara, (58) 555-5555"

@ORIGIN: Define el nombre de dominio de la zona (útil para realizar INCLUDES)
SOA: “Start of Authority”, nos dice QUIEN es la autoridad en un dominio, tiene la siguiente forma:

IN SOA MNAME: Lo que sigue a la palabra SOA es el MNAME, representa el NOMBRE MAESTRO (MASTER NAME) o Servidor maestro y primario de la ZONA, el servidor maestro no solamente debe estar listado en nuestra lista de NS (NameServers) sino que además, debe ser el primero.

Le sigue al MNAME el responsable de la zona (RNAME), es el correo (en el formato “nombre.dominio”) de quien es el administrador del dominio, dicho correo DEBE existir (he visto quienes lo configuran como “root.midominio” pero, envías un correo a dicha dirección y rebota), por cuestiones de convenciones, se recomienda que sea alguno de los alias administrativos “hostmaster” ó “postmaster” (RFC 2142).

Luego le siguen los valores de de la zona, el primero es el SERIAL, un valor incremental, que debe ser cambiado para notificar al demonio RNDC (y al resto de servidores) que la zona ha sido cambiada y que notifique los cambios, puede ser cualquier valor, por convención (Los libros de O’really media ayudaron “algo”) el serial de la zona tiene la forma  “YYYYMMDDXX” donde los primeros 8, son la fecha (ej: 20130520) y los 2 últimos, un par de dígitos incrementales (representan el número de cambios realizados durante el día).

Los tiempos de la Zona

Los valores de la zona son importantes para describir cómo se comportan las actualizaciones de la misma, el primero es el valor REFRESH e indica la cantidad de segundos que una zona puede esperar para ser refrescada “o transferida” a un servidor esclavo, por ejemplo, dicho valor para zonas muy volátiles puede ser pequeño, pero no menor a 1200 segudos, y para zonas con pocos cambios, entre 8 a 12 horas (43200), en la mayoría de los casos, como BIND notifica de los cambios, se puede implementar un refrescamiento de un día, o más incluso (86400).

Retry, es el valor de re-intento, ¿qué pasa si contacto una zona y esta falla?, un servidor esclavo puede esperar una cantidad para re-intentar la consulta/transferencia desde el maestro, debe ser un valor bajo, entre una hora (3600) a 3 minutos (180).

Expire: representa el tiempo que una zona es “válida” luego de una caída del servidor maestro de la zona, debe ser siempre un valor alto, entre 2 a 4 semanas (1209600 a 2419200), para permitir cualquier caída “larga” del sistema.

Minimun TTL: o “negative caching time”, es importante para la “operación” de los Cache de DNS, es el tiempo máximo en que un servidor de DNS puede responder “correctamente” cuando se presenta un NXDOMAIN en la respuesta autoritativa de la zona, como DNS es un servicio que debería garantizar la estabilidad ante todo, dicho valor no debe ser mayor a 10800 segundos (3 horas como máximo).

Definiendo Name Servers

Los “Name Servers” son simplemente, los servidores que responden como “autoritativos” (dueños) de la zona DNS, de los múltiples errores que puede haber con esto, hay 4 de consideración:

  • Single point of Failure: Esto representa la imposibilidad de responder desde varios puntos, sea porque el dominio no configura “al menos” 2 servidores de nombres (la RFC 2182 indica que deberían existir *al menos* 2 ó 3 servidores de nombres para un dominio) ó porque los DNS de este dominio están todos en la misma sub-red (se daña el switch o el router de esa sub.net y ¡adiós DNS!).
  • Missing Nameservers: A veces, configuramos 2 o más servidores de nombres (como el caso del Ministerio de Educación Superior: http://www.intodns.com/mppeu.gob.ve) y los servidores que configuramos están, o fuera de servicio (apagados) o han dejado de responder autoritativamente a nuestro dominio, como Administrador de DNS, es nuestra responsabilidad mantener la red de resolución de nombres de nuestro dominio.
  • Stealth NS records: Se refiere a que, en nuestra zona DNS, hacemos referencia a los NS primario y secundario de nuestro dominio, pero, ante nuestro registrar (ejemplo: NIC.VE de Venezuela) indicamos otro servidor, causando qué, cuando uno consulta a NIC.VE por “mppeu.gob.ve” este responda “dns.mes.gob.ve es el autoritativo de la zona MPPEU”, si vas y le preguntas a dns.mes.gob.ve, este indicará que “le he delegado esa responsabilidad a dns.mppeu.gob.ve”, causando varias consultas, donde solo debería ocurrir una, además, la zona mppeu.gob.ve no contiene registros NS para “mes.gob.ve”, por lo que la zona está desconfigurada (en pocas palabras, un dominio está respondiendo como un autoritativo, de otro dominio, pero ese otro dominio, no lo reconoce en sus NS, como su autoritativo).
  • Recursive Queries: estamos acostumbrados a ver los DNS de Windows Server, que responden a todo (direcciones propias y además ajenas) esto, conocido como “recursive resolver” es un error, ya que tu servidor de nombres puede responder por “cualquier cosa” y no solamente por tu dominio, en este caso podemos ver:
dig @dns.mes.gob.ve google.com.ve
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @dns.mes.gob.ve google.com.ve
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65202
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 8

;; QUESTION SECTION:
;google.com.ve. IN A

;; ANSWER SECTION:
google.com.ve. 41 IN A 74.125.140.106
google.com.ve. 41 IN A 74.125.140.147
google.com.ve. 41 IN A 74.125.140.99
google.com.ve. 41 IN A 74.125.140.103
google.com.ve. 41 IN A 74.125.140.104
google.com.ve. 41 IN A 74.125.140.105

Acá podemos ver cómo el servidor autoritativo del Ministerio del Poder Popular para la Educación Superior (que agrupa las universidades!, una de ellas, la que da informática y sistemas donde estudié, xD) responde consultas como un servidor de nombres recursivo, exponiéndolo fácilmente a una denegación de servicio basada en consultas recursivas envenenadas.

Como dato final de los nameservers, el MNAME en el SOA, siempre debería estar listado en la lista de Name Servers de la Zona, por ello un “MNAME” indicando “localhost” no solo es un error, sino una mala (muy mala) interpretación de los conceptos de DNS.

El “puntero de la zona” y WWW

¿qué pasa si escribimos un dominio sin agregar WWW?, lo que debería ocurrir, es ser enviado al servidor web asociado a WWW, sin embargo si visitan http://seniat.gob.ve verán que no abre ninguna página web y su navegador web le indicará que dicha página no existe, ¿a qué se debe esto?, pues a la ausencia del puntero de la zona (el registro A más básico, sin nombre), este se escribe así:

@       IN      A       144.76.25.228

Y representa que, en ausencia de cualquier sub-dominio, se entregará este servidor al cliente, un simple registro que evita muchos problemas.

Otro caso es WWW que DEBE ser un puntero A y no un CNAME, ¿por qué?, porque entonces cuando yo pido http://www.cnti.gob.ve, entonces este me enviará a otro nombre, que a su vez, me devolverá la IP, causando 2 consultas donde solo debería existir una, ¿comprenden?

;; QUESTION SECTION:
;www.cnti.gob.ve. IN A
;; ANSWER SECTION:
www.cnti.gob.ve. 0   IN CNAME  cnti.gob.ve.
cnti.gob.ve. 1200    IN A      190.9.128.98

Esto se solventa con la definición de un puntero @ y un puntero A para WWW, esto también aplica para servidores de correo (RFC-821 Section 3.1) los nombres deben ser siempre punteros A principales, jamás deben ser CNAME; la confusión aplica cuando preguntas por “www.google.com” y este responde que es un CNAME, la única razón para realizar esto, cuando tienes una granja de servidores y un servicio de aceleración permite entregar el servidor con el mínimo TTL más próximo a tí, por lo que el segundo lookup al DNS, es superfluo:

www.google.com. 36545 IN CNAME www.l.google.com.
www.l.google.com. 294 IN A 209.85.153.104

Pero ese no es el caso del CNTI, ¿cierto?.

El intercambio de correo

Otro de los lugares donde se cometen más “errores” es en la configuración del intercambio de correo, por ejemplo, seniat.gob.ve|seniat.gov.ve indica en su configuración que su servidor MX es correo.seniat.gov.ve, sin embargo, en la vida real (y hasta finales del año pasado, ultima vez que revisé), cuando recibes correo del SENIAT, quien lo envía es un servidor Microsoft Exchange que se reporta como:

nomacovasuli.seniat.gov.ve
(
Received: from nomacokadru.seniat.gov.ve ([10.156.80.84]) by nomacovasuli.seniat.gov.ve with Microsoft SMTPSVC(6.0.3790.4675);
Received: from RECEOCKADRU.seniat.gov.ve ([10.163.128.74]) by nomacokadru.seniat.gov.ve with Microsoft SMTPSVC(6.0.3790.4675);
)

Incluso en el HELO/EHLO del servidor de correo, sin embargo, dicho puntero A (o CNAME) no se encuentra en la zona SENIAT.GOV.VE, por lo que cualquier resolución inversa es imposible.

El otro error, es cuando, bueno, un día se dañó el servidor de correo, lo cambiaron, pero no actualizaron las entradas MX, por ejemplo:

http://www.intodns.com/inces.gob.ve

En este caso, indica qué el intercambiador es:

10   mail.inces.gob.ve   200.11.149.166

Sin embargo, cuando recibes correo de allí, lo recibes de:

Received: from mail.inces.gob.ve ([200.11.149.162]) <--- IP verdadera del cliente
        by mx.google.com with ESMTP id gz2si4186023vcb.4.2012.12.20.16.22.19;

Lo que representa un verdadero “dolor de cabeza” si comienzo a bloquear como “Lame Server” a un servidor que me desea entregar un correo a nombre de “inces.gob.ve” pero dicho servidor no se corresponde al MX que debería entregarmelo.

Y lo peor, es la configuración de IP del host que “hostea” este servidor de correo:

Received: from localhost (localhost [127.0.0.1])
	by mail.inces.gob.ve (Postfix) with ESMTP id E0ED556DC2F

Exponiendo a los “hackers” incluso las IPs “privadas de la sub.-red:

Received: from [10.50.0.58] (unknown [10.0.0.220])
	by mail.inces.gob.ve (Postfix) with ESMTP id BD5FD56DE4C

El otro problema que suele ocurrir con servidores de correo (precisamente de este mismo dominio), es la ausencia de un puntero reverso (reverse PTR record) en la zona inversa de quien me provee los DNS, por ejemplo, en CANTV (quien le provee las IPs públicas a INCES), debería existir una zona inversa:

166.149.11.200.in-addr.arpa -> mail.inces.gob.ve

Y esta zona inversa retornar el nombre del servidor de correo (¿no?, esa IP es mía, única y debería retornar el nombre de mi servidor), sin embargo ocurre que:

166.149.11.200.in-addr.arpa ->  200-11-149-166.estatic.cantv.net

Si en la configuración de mi correo, decido no aceptar correo de servidores que no tienen puntero reverso (útil para evitar correo de servidores de SPAM, que contratan cualquier VPS y montan allí un servidor de correo LAME), como mínimo este correo caerá en la carpeta de SPAM (o no llegará) y los administradores se preguntarán, ¿por qué?

Tips finales

En la semana de las elecciones, un grupo de hackers y chicos de lulzsec, se dedicaron a atacar servidores de la APN de Venezuela, considero que es muy importante entender que más de la mitad de la responsabilidad la tienen malos administradores, que desconocen mucho de lo que, por responsabilidad, la nación les ha encomendado proteger (como aquél, que le toca la seguridad de servidores y solo allí comienza a aprender “iptables” en vez de utilizar herramientas ya probadas, o el que configura un postfix-courier sin conocer en lo más mínimo las RFC orientadas a servidores de correo).

Insisto, no me puedo considerar un “experto” de DNS, pero cuando hacemos el siguiente experimento:

ping localhost.saren.gob.ve
PING localhost.saren.gob.ve (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.042 ms

Me pregunto ¿en qué estaba pensando el administrador que creó ese puntero A apuntando a “localhost”? o ¿en qué estaba pensando VTELCA al contratar a una empresa (DATTATEC) para administrar los DNS y sin embargo, dicha empresa ni siquiera responde a dichos Dominios?

http://www.intodns.com/vtelca.gob.ve

dig @200.58.116.42 -t SOA vtelca.gob.ve
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @200.58.116.42 -t SOA vtelca.gob.ve
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44763
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
 
;; QUESTION SECTION:
;vtelca.gob.ve. IN SOA

Considero importantísimo, que si se desea “pregonar” la “eficiencia o nada”, primero comencemos por admitir que estamos haciendo muchas cosas mal, espero que este artículo sea un “granito de arena”, para que “manual en mano”, los administradores de DNS comiencen a asumir su responsabilidad, de leer las RFC y verdaderamente, aprender y configurar DNS.

Saludos y ¡Happy Hacking!

Actualización

Según la RFC-1912, Se deben crear las zonas “directas” y “reversas” a la sub-net loopback (localhost <> 0.0.127.in-addr-arpa) para evitar “el error” qué resoluciones “127.0.0.1” alcancen a los ROOT-SERVERS; dichas zonas deben estar en una “vista interna” para no causar tráfico innecesario a los ROOT-SERVERS y al sistema DNS mundial, y sin embargo, el 1% de las resoluciones DNS que llegan a los ROOT-SERVERS son para la dirección “127.0.0.1”, algo así como lo que pasa en muchas Zonas DNS de CANTV:

;; ANSWER SECTION:
localhost.saren.gob.ve. 21600 IN A 127.0.0.1

Delegar a los DNS, la responsabilidad de resolución de DNS “internos” y de los hosts (/etc/hosts ó windows/system32/drivers/hosts) o de la zona loopback, es un muy mal entendimiento del concepto plasmado en la RFC-1912.


		

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 20 abril 2013 en Blogeando!, Cultura Libre, La nota del día, Linux, PlanetaLinux y etiquetado en , , , , , . Guarda el enlace permanente. 7 comentarios.

  1. Muy buen Articulo me tope con el buscando la solución al (reverse PTR record), sabes como solucionar el problema ?
    “…166.149.11.200.in-addr.arpa -> 200-11-149-166.estatic.cantv.net…” CANTV tiene alguna herramienta online? solicitud en linea? o conoces algún procedimiento? Espero puedas ayudarme. Gracias!!!

    • Muchas de las zonas reversas de CANTV no son “transferibles”, es decir, CANTV no configura punteros reversos a menos qué, obviamente, se tenga una cuenta con ellos y se notifique personalmente (utilizando para ello, sus contactos administrativos).
      No, CANTV no tiene ninguna herramienta automática u online para la gestión de sus reversos, todo se hace por solicitud escrita.

  2. Luis Alejandro Vázquez

    Saludos Jesús: te planteo una situación que es la de las mayorías de las instituciones públicas de este país. Tengo uno (o dos) aba y por lo tanto mis IP’s son dinámicas, pero tengo que instalar un servidor DNS para manejar un dominio .gob.ve: Cómo lo hago? qué recomendarías hacer para tener un servicio DNS decente si no tengo acceso a una IP fija?, existe algún proveedor de DNS que me pueda prestar el servicio de forma confiable? Cuál? Mil gracias por tus respuestas porque se, que no son sólo para mi, sino para una cantidad importante de gente que anda en las mismas! Saludos…

    • Uno de los proveedores de DNS gratuito más confiables que conozco es xname, el otro es clouDNS, pudieras crearte una cuenta allí y apuntar los NS de NIC.VE a dicho proveedor gratuito.
      Ahora, si quisieras administrarlos tú (jamás recomendado en tu situación de conectividad, los ABA sirven para descargar, pero la velocidad de subida es pésima), tendrías que montar en algún VPS un DNS, apuntar a NIC para allá y hacerlo un esclavo de copia de unos servidores en tu red local, así, cambias localmente pero lo sirves allá arriba.
      Es de lo que se me ocurre …
      Saludos!

  3. amigo saludos por cuestiones de la vida me dejaron a cargo de los servidores de un instituto llamado INASS y tengo fuertes problemas con los dns en la actualidad, no están resolviendo las direcciones internas, las personas que lo configuraron, crearon 3 zonas, una .gob.ve otra inass sola y una inass.int y no consigo algo parecido en la web, mi correo es roger.herrera@inass.gob.ve, por favor enviame tu correo para hacerte llegar los archivos a ver como me puedes ayudar, gracias

  1. Pingback: [DNS] ¿Cómo afecta nuestra ineficiencia y desidia? | Phenobarbital con Soda!

  2. Pingback: carta abierta al director general de conatel, william castillo, (y por extensión al ministro Manuel Fernández) | Mis dos céntimos de bolívar débil.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: