Archivo de la etiqueta: dns

Clonar registros DNS externos en Microsoft DNS Server

Ya explicamos en otro post como resolvimos el problema de conectar la oficina de Sevilla, que sólo podía tener IP dinámica. Para mantener el direccionamiento actualizado, en el gateway de la oficina de Sevilla tenemos un pequeño script programado que comprueba si la IP asignada por nuestro ISP ha cambiado y en caso afirmativo lo modifica en nuestro proveedor DNS.

Sin embargo, y dado que en Plain Concepts usamos split-brain DNS, necesitamos alguna forma de propagar ese cambio a nuestros DNS internos. Aunque esto podemos conseguirlo de muchas formas, dado que asumimos que esta situación en la que una de nuestras oficinas sólo tiene IP dinámica será temporal, queríamos solucionar el problema de la forma más sencilla posible, pero sin que por ello dejase de ser elegante.

Como era de esperar, todo lo que necesitábaos era una estupenda combinación de PowerShell y el programador de tareas. Una de las grandes novedades del servidor DNS de Windows Server 2008 R2 fue que este podía administrarse desde PowerShell, dejando -desde mi punto de vista- de lado al ya clásico dnscmd.exe. Así pues construí rápidamente un pequeño script que realiza las siguientes tareas:

  1. Consulta a un DNS externo (como Google u openDNS) la resolución del dominio pertinente, ej: oficina-sevilla.plainconcepts.com. Recordad que este dominio lo mantenemos siempre actualizado en nuestro proveedor DNS.
  2. Obtenemos de nuestro DNS interno el registro pertinente al dominio oficina-sevilla.plainconcepts.com. Como de costumbre, se nos devuelve un objeto de PowerShell.
  3. Clonamos el objeto y aplicamos la IP obtenida en el paso 1.
  4. Actualizamos el registro de nuestro DNS interno con el nuevo objeto clonado

El resultado sería el siguiente:

Todo lo que nos quedaría ahora es incluir este escript en el programador de tareas para que se ejecute automáticamente de forma periódica y tendríamos la IP siempre sincronizada con el DNS externo.

Happy resolution!

Aging y Scavenging en DNS

Los equipos con Windows permiten actualizar dinámicamente su registro A en el servidor DNS local al que consultan, permitiendo que los administradores tengamos una visión y control de los equipos que están conectados a nuestra red, así como tener resolución DNS de los equipos cliente de manera automática. Sin embargo, si el registro no se elimina correctamente cuando los equipos salen de la red, se quedan como registros obsoletos, lo que puede darnos varios quebraderos de cabeza:

  • Si un número elevado de registros obsoletos permanece en las zonas, pueden ocupar espacio en disco del servidor y provocar transferencias de zona innecesariamente largas.
  • Los servidores DNS que cargan zonas que contienen registros obsoletos pueden usar información no actualizada para responder consultas de clientes, lo que puede hacer que los clientes experimenten problemas de resolución de nombres en la red.
  • La acumulación de registros obsoletos en el servidor DNS puede reducir su rendimiento y capacidad de respuesta.
  • En algunos casos, la presencia de un registro obsoleto en una zona puede evitar que otro equipo o dispositivo use un nombre de dominio DNS.

Es por eso que los servidores DNS de Microsoft cuentan con varios mecanismos que permitan el borrado de estos registros obsoletos. Al final todo gira en torno a 3 conceptos: marca de tiempo en los registros (timestamp), envejecimiento (aging) y borrado de los considerados obsoletos (scavenging).

Cuando te pones a jugar con estos valores y con el miedo a que se borren registros que realmente no están obsoletos, con el paso del tiempo hemos visto muchas dudas que pretendemos resolver con este “Preguntas y respuestas frecuentes”:

1. El valor de TimeStamp (Marca de Tiempo) ¿indica la hora y la fecha en la cual el registro fue creado?

Cuando una máquina cliente utiliza actualizaciones dinámicas para registrar su entrada en DNS, el timestamp se crea/modifica en los siguientes casos:

  1. Cuando el registro es creado por primera vez por un cliente que no existía en la zona, se considera una “Actualización, y el timestamp es establecido con la fecha y la hora del sistema en ese momento.

  2. Si el cliente tiene un registro ya creado en DNS y cambia su dirección IP, se considera una “Actualización, y se actualiza el timestamp con la fecha y la hora del sistema en ese momento.

  3. Si el cliente tiene un registro ya creado en DNS y mantiene la misma dirección IP, se considera un “Refresco”, y la actualización del timestamp dependerá de la configuración de la zona (lo veremos más adelante).

  4. Si el DHCP es el propietario de los registros, y está configurado dentro del grupo DnsProxyUpdate para la creación de los registros en DNS, la actualización de los timestamp los llevará a cabo cuando renueve una concesión IP.

    Una vez el timestamp se ha establecido para un registro, este valor es replicado a todos los servidores que mantienen la zona DNS donde se encuentra dicho registro. Para ello el Aging/Scavenging debe estar habilitado en la zona.

    2. Si se configura el Scavenging con un valor de 7 días y no se reinicia el cliente en 7 días, ¿el registro correspondiente es borrado?

    Creo que lo mejor para entender la respuesta a esta pregunta es resumir como funciona el proceso de Aging y Scavenging y los tiempos que se manejan en cada caso.

    Antes de que un servidor DNS vaya a comprobar si un registro es susceptible de ser eliminado, deberemos habilitar Aging/Scavenging en la zona donde se encuentre el mismo.

    Para acceder a la configuración de Aging/Scavenging para una zona deberemos hacer click derecho sobre la misma, seleccionar “Propiedades”, pestaña “General” y pulsamos en el botón “Aging”.

    image

    Cuando estableces por primera vez Aging/Scavenging para una zona, la fecha y la hora que vemos en la parte inferior de la imagen se establece con la fecha y hora actual del sistema (la hora se redondea hacia abajo) + el valor de refresco “Refresh interval”.

    Ese valor indica el primer momento en el que la zona es susceptible de poder ejecutar el servicio de Scavenging (borrado de registros obsoletos).

    Una vez que se ejecute el servicio, comprobará los registros para ver cuales son susceptibles de borrado, esto es, los que hayan pasado sin actualizarse durante su intervalo de No-Refresco + Refresco.

    Refresh and No-Refresh intervals

    Estos valores son los que indican los tiempos de espera hasta que el servicio de Scavenging pueda actuar. Ambos deben expirar antes de que un registro pueda ser borrado.

    El valor de No-Refresco es un periodo de tiempo durante el cual un registro DNS no puede ser “refrescado”. Como vimos antes, consideramos un “refresco” a una actualización dinámica donde no existe un cambio de IP para el registro, sino que simplemente se actualiza el Timestamp. Si un cliente cambia su IP, es  considerada una “actualización”, la cual está exenta del tiempo de No-Refresco, y su entrada será actualizada siempre.

    Este intervalo de No-Refresco tiene como propósito reducir el tráfico de replicación entre los servidores DNS en los casos en los que el cliente no ha cambiado su configuración. Un cambio en un registro es un cambio que sí que debe ser replicado.

    Una vez que el Timestamp del registro + el intervalo de No-Refresco acaban, entramos en el Intervalo de Refresco. Este intervalo es en el cual están permitidos los “refrescos”, es decir, cuando se permite que un registro actualice su Timestamp.

    Durante este intervalo es cuando los clientes deben actualizar su Timestamp para “demostrar” que siguen activos. Una vez se actualice, será replicado al resto de servidores DNS que mantienen la zona, y ese registro volverá a entrar en el intervalo de No-Refresco.

    Si por cualquier razón, un cliente no consigue actualizar dinámicamente su Timestamp durante el intervalo de refresco, pasa a ser elegible de ser eliminado por el Scavenging.

    Nota: Debemos establecer los valores para los intervalos de No-Refresco y de Refresco de manera que estemos seguros de que les estamos dando tiempo suficiente a los clientes a realizar varios intentos de registro o actualización durante el intervalo de Refresco.

    Opciones de Scavenging en el Servidor

    Ahora mismo ya tenemos tanto los registros (con el Timestamp) como la zona (con lo que hemos hecho en el paso anterior) preparadas para poder ser ejecutado el proceso de Scavenging.

    La configuración del servicio de Scavenging a nivel de Servidor se establece haciendo clic derecho en el servidor dentro de la consola DNS, seleccionando Propiedades, pestaña Avanzada y habilitando “Enable automatic scavenging of stale records”.

    image

    El periodo que establecemos aquí, es el intervalo que va a esperar el servicio de Scavenging para ejecutarse en cada ciclo. Cuando este servicio se ejecuta, va a registrar un Evento 2501 que indica cuantos registros van a ser eliminados. Un Evento 2502 va a ser registrado cuando no haya ningún registro que eliminar.

    Sólo es necesario tener configurado Scavenging en un servidor, dado que los datos de la zona DNS serán replicados a todos los servidores que mantienen dicha zona.

    Aunque podríamos establecer el servicio de Scavenging en cualquier servidor que mantenga la zona, mi recomendación es hacerlo sólo en uno. La razón es que si el servidor falla al realizar el Scavenging, el problema no es demasiado grave, y además tendremos un único sitio donde comprobar qué es lo que ha fallado.

    Podemos saber cuando el servidor va a realizar el próximo proceso de Scavenging, observando los últimos eventos 2501 o 2502 y añadiendo el periodo de Scavenging que hayamos establecido en el paso anterior.

    Podemos también forzar manualmente la ejecución del servicio de Scavenging haciendo clic derecho en el servidor y seleccionando la opción “Scavenge Stale Resource Records”.

    Una vez tengamos todos los parámetros configurados (Actualizaciones dinámicas habilitadas en la zona, Aging/Scavenging en la zona, Scavenging en el servidor, etc), el servicio de Scavenging, que se ejecutará con una periodicidad que hemos establecido en el paso anterior, comprobará el Timestamp de cada registro en las zonas que tengan habilitado Aging/Scavenging y comparará si la fecha/hora actual es superior al valor del Timestamp + No-Refresh + Refresh, y si es así, eliminará el registro.

    image

    3. ¿Es necesario reiniciar el cliente cada 7 días para que actualice su registro en DNS?

    No, por defecto, los clientes Windows intentarán realizar una actualización dinámica de su registro DNS cada 24 horas.

    4. Si se añade un registro en DNS de manera manual, cual es el valor del Timestamp y cuál es el comportamiento del Scavenging en este caso?

    Cuando un registro en DNS es añadido de manera manual, el Timestamp se establece como “estático” lo que supone un valor de 0. En este caso el servicio de Scavenging ignorará estos registros y no los eliminará.

    5. Buenas prácticas

    Fase de configuración:

    1. Debemos asegurarnos de que el servicio de Scavenging está deshabilitado a nivel de servidor en todos los DNS.

    2. Habilitamos Aging/Scavenging en las zonas en las que queramos tener esta funcionalidad. Estableceremos los intervalos de No-Refresco y Refresco como vienen por defecto (7 días). La recomendación es que estos valores sean inferiores al tiempo de concesión del DHCP (en nuestro caso de 8 días) para evitar resultados inconsistentes.

    3. Sumamos la fecha actual más el intervalo de No-Refresco más el intervalo de Refresco, y volvemos en esa fecha a revisar si los Timestamp de los clientes han sido actualizados correctamente.

    Fase de saneamiento:

    Comprobamos si existe algún registro que tenga su Timestamp anterior a los tiempos de No-Refresco+Refresco (no se ha actualizado durante el tiempo que hemos esperado). Si existe alguno, tenemos que revisar si se trata de un cliente activo ya que puede haber fallado la actualización dinámica y debemos corregirlo antes de continuar. Aunque sea costoso, es importante realizar una comprobación exhaustiva en este momento.

    No debemos continuar a menos que podamos explicar los registros obsoletos, ya que serán eliminados en la siguiente fase.

    Fase de activación:

    El paso final es habilitar Scavenging a nivel de servidor. Como vimos antes es recomendable hacerlo únicamente en un servidor DNS.

    6. Podemos encontrar mucha más información en los siguientes artículos:

    Using DNS Aging and Scavenging

    http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx

    Don’t be afraid of DNS Scavenging. Just be patient.

    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Using DNS servers with DHCP

    http://technet.microsoft.com/en-us/library/cc787034(WS.10).aspx

    Integrating DNS with DHCP

    http://technet.microsoft.com/es-es/library/cc757867(WS.10).aspx

    Espero que os sea de utilidad.

    ¡Hasta la próxima!

    Asegura la legitimidad de tu email con los registros SPF

    Los que nos dedicamos a la mensajería y la colaboración tenemos bien presente que el SPAM y el phishing son dos de los grandes enemigos a los que debemos enfrentarnos, dos tipos de amenzadas que tienen el denominador común de la legitimidad del email, entendiendo por email legítimo aquél que se ha generado por parte de una persona al cargo de un buzón que se encuentra en el dominio del remitente que indica.

    Desde hace ya más de una década hay esfuerzos más o menos coordinados para luchar contra el correo basura a través de múltiples estrategias entre las que podemos comentar:

    • Crear listas negras que incluyan servidores SMTP que se encuentren configurados como open relay,una configuración que permite que un tercero pueda utilizar esa máquina para enviar correo usando a su vez identidades falsas.
    • Establecer una regulación de las listas de distribución y correos masivos por parte de organizaciones e individuales que garantice que la recepción de dichos mensajes es autorizada por parte de sus correspondientes destinatarios, que a su vez pueden anular su suscripción en cualquier momento.

    Sin embargo, las distintas estrategias planteadas con anterioridad no han sido suficientemente prácticas para erradicar completamente estas malas prácticas. Es por ello que en este artículo os vamos a hablar del Sender Policy Framework (SPF), que es una solución eficaz a estos problemas a medida que se va implementando cada vez más en los servidores SMTP de todo el mundo.

    El SPF es un sistema de validación de email extremadamente sencillo que se apoya en la infraestructura DNS de las distintas organizaciones. El concepto es bien sencillo: a través de nuestro DNS vamos a declarar qué servidores están autorizados a enviar email a nombre de los dominios que tenemos en nuestra propiedadComo la información de los DNS es pública, cualquier sistema SMTP puede consultarla para cotejar si el servidor desde el que el correo electrónico ha sido enviado figura como autorizado por el listado.

    La sintaxis y la forma de operar con el registro es bien sencilla. Veamos un ejemplo real con el SPF de Plain Concepts:

    Sin ser demasiado expertos podemos ver una serie de IPs declaradas. En efecto, todas ellas constituyen direcciones que potencialmente pueden tener la capacidad de enviar correos electrónicos a nombre de plainconcepts.com y que nosotros estamos declarando como legítimas.

    ¿Cómo construimos un buen SPF para nuestro dominio?

    La sintaxis es tremendamente sencilla. El concepto clave es: si el mensaje no está gestionado o enviado por cualquiera de las cosas que declaremos, entonces especificamos una política por defecto. Para ello, seguimos los siguientes pasos para… imaginemos el dominio cantoso.com:

    1. Creamos un nuevo registro TXT en cantoso.com. Si quisiéramos declarar SPF en subdominios, deberemos crear una entrada por cada uno de ellos.
    2. El valor del registro debe comenzar por v=spf1 donde especificamos que vamos a declarar un SPF y su versión.
    3. Lista de máquina autorizadas a enviar correo en nombre de nuestro dominio. Para ello podemos usar las siguientes palabras clave:
      • A: si vamos a declarar un nombre declarado como registro A ó AAAA. Ejemplo: a:mail.plainconcepts.com
      • IP4: si vamos a declarar una dirección IPv4 o un rango. Ejemplo: ip4:2.212.170.67 ó ip4:192.168.0.0/24
      • IP6: similar al anterior, pero usando direcciones o rangos IPv6.
      • MX: si vamos a usar una resolución de registro MX. Ejemplo: mx:plainconcepts.com.
      • INCLUDE:  que utilizaremos si vamos a usar las políticas SPF declaradas en otro dominio, muy usada en entornos cloud. Ejemplo: include:spf.protection.outlook.com.
      • ALL: esta palabra clave hace match con todo.
      • La palabras clave A, MX, e INCLUDE implican resolución de nombres DNS. SPF limita a 10 consultas DNS, por lo que debemos tener cuidado de no abusar de los registros que hacen uso de ellas.
    4. Cerramos nuestra cadena con -all. Usando -all especifica que todo lo que no haya cumplido con los elementos anteriores, fallará la validación SPF. Una alternativa común es usar ~all que nos indica que los mensajes serán aceptados pero etiquetados.

    Así, volvamos a echar un vistazo a la cadena de plainconcepts.com y el significado de cada elemento:

    Examinemos los elementos:

    • v=spf1 es la declaración del registro SPF.
    • include:spf.protection.outlook.com deriva de nuestro uso de Office 365, por lo que incluimos sus servidores SMTP como autorizados para nuestro dominio.
    • include:sendgrid.net es similar al anterior, pero relativo a los servicios de SendGrid.
    • ip4: todas estas entradas están autorizadas a enviar correo en nuestro nombre.
    • -all: si la dirección IP del remitente no entra dentro de ninguna de las reglas anteriores, especificamos que la validación falla.

    ¿Sólo con establecer este registro estamos protegidos?

    Lamentablemente no, aunque hemos hecho la parte que nos toca en relación a la declaración del SPF. El registro como tal sólo proporciona información a los MTA y es decisión de cada uno hacer validación mediante este mecanismo o no.

    Si un servidor SMTP usa SPF, su flujo sería parecido al siguiente:

    1. mail.plainconcepts.com recibe un email de jorge@cantoso.com desde la IP 193.153.214.55.
    2. mail.plainconcepts.com coteja la IP 193.153.214.55 con el SPF declarado por cantoso.com, que resulta ser “v=spf1 ip4:2.213.33.45 -all”.
    3. La IP no coincide con ninguna de las declaradas y la validación falla.
    4. mail.plainconcepts.com considera el correo ilegítimo y lo marca como tal.

    Si jorge@cantoso.com envía un email a paco@fabrikam.comFabrikam no implementa validación SPF, de poco sirve a cantoso.com tener publicada esa información en el DNS para ese caso concreto.

    ¿Cómo activo el SPF en Office 365?

    Por defecto Office 365 tiene DESACTIVADA la validación SPF. Sin embargo, activarlo es un proceso realmente sencillo:

    1. Iniciamos la sesión como administrador de Exchange Online.
    2. Vamos a Protección -> Filtro de contenido.
      spf1
    3. Seleccionamos la política por defecto y la editamos.
    4. Nos dirigimos a Opciones avanzadas -> Registro SPF: error
      spf2
    5. A partir de este momento Office 365 empieza a realizar validaciones SPF.

    Espero que este artículo os haya servido para aprender una forma sencilla y eficaz de proteger y legitimar tanto la identidad de vuestro correo electrónico saliente, como de aquellos mensajes entrantes que pasan por vuestras estafetas SMTP.

    Happy mailing!

    Enlace relacionado: RFC 7208 – Sender Policy Framework
    Enlace relacionado: SPF – Wikipedia