Bienvenidos a la página personal de José Domingo Muñoz Rodríguez, aquí podrás encontrar…

Accede a las entradas de mi blog donde escribo de Informática y Educación.

Blog Pledin

Accede a los materiales de los cursos que he impartido.

Plataforma Pledin

Accede a los contenido de los módulos de FP que estoy impartiendo en la actualidad.

Módulos FP

Últimos posts...

Resolución de nombres de dominios en sistemas Linux

dns

Los diferentes servicios que nos ofrecen la posibilidad de resolver nombres de dominio a direcciones IP dentro de un sistema operativo GNU/Linux han ido evolucionando a lo largo del tiempo. En este artículo quiero introducir la situación actual acerca de este tema, y presentar los distintos servicios involucrados en la resolución de nombres.

Conceptos relacionados con la la resolución de nombres de dominio

Antes de comenzar a estudiar con detalle los distintos mecanismos de resolución, vamos a repasar algunos conceptos que nos serán necesarios:

  • Servidor DNS: Ofrece un servicio de resolución de nombres de dominio, entre otras cosas. Los nombres de dominio siguen el sistema de nombres de dominio (Domain Name System o DNS, por sus siglas en inglés) ​, que es un sistema de nomenclatura jerárquico descentralizado para dispositivos conectados a redes IP como Internet o una red privada. Los servidores DNS se pueden consultar, por ejemplo para obtener la dirección IP a partir de un determinado nombre de host o nombre de dominio. Tradicionalmente en los sistemas GNU/Linux el fichero donde se configura el o los servidores DNS que se utilizarán para resolver los nombres es /etc/resolv.conf.
  • Resolución estática: Es un sistema de resolución de nombres de dominios a direcciones IP, que está configurado de manera estática en un ordenador. En los sistemas GNU/Linux se utiliza el fichero /etc/hosts para guardar la correspondencia entre nombre y dirección.
  • NSS: El Name Service Switch o NSS es una biblioteca estándar de C que en sistemas GNU/Linux ofrece distintas funciones que los programas pueden utilizar para consultar distintas bases de datos del sistema. En concreto con este sistema se ordena las distintas fuentes para consultar las distintas bases de datos, por ejemplo de usuarios, contraseñas, nombres de hosts,… En este artículo la base de datos que nos interesa corresponde a los nombres de dominios o nombres de hosts. Esta base de datos se llama hosts y como veremos en el fichero /etc/nsswitch.conf se configura el orden de consulta que se realiza para resolver el nombre de un dominio a su dirección IP.

El fichero /etc/resolv.conf

Como hemos comentado, este archivo especifica los servidores DNS que el sistema utilizará para resolver nombres de dominio a direcciones IP. Los parámetros más importantes que podemos encontrar son:

  • nameserver: Esta línea define los servidores DNS que el sistema utilizará para resolver nombres de dominio. Pueden haber múltiples líneas nameserver, una para cada servidor DNS. El orden es importante ya que se intentará resolver el nombre utilizando el primer servidor, si este no funciona se intentará con el siguiente y así consecutivamente.
  • search: Esta línea especifica el dominio de búsqueda para las consultas de resolución de nombres de dominio. Si intentas resolver un nombre de dominio que no está completamente cualificado (es decir, sin un sufijo de dominio), el sistema intentará agregar los dominios de búsqueda especificados aquí para completar el nombre antes de enviar la consulta al servidor.
  • domain: Similar a search, domain especifica el dominio de búsqueda para las consultas de resolución de nombres de dominio, pero solo acepta un único dominio en lugar de una lista.
  • options: Esta línea se utiliza para especificar diversas opciones de configuración, como el tiempo de espera de resolución, la retransmisión de consultas, entre otros.

Ejemplo de configuración de etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
domain example.com
search example.com mycompany.com
options timeout:2 attempts:3

Estos parámetros se suelen recibir de forma dinámica por medio de un servidor DHCP, aunque también lo podemos indicar de forma estática en la configuración de red del sistema. Normalmente tenemos algún demonio instalado en el sistema, como resolvconf que es el encargado de generar el fichero /etc/resolv.conf a partir de la configuración de red que hayamos especificado.

En este caso no debemos cambiar directamente el fichero /etc/resolv.conf porque el programa resolvconf puede reescribirlo en algunas circunstancias, por ejemplo cuando se renueva la concesión del servidor DHCP.

Si queremos añadir contenido de forma estática al fichero /etc/resolv.conf es necesario escribir el contenido en el fichero /etc/resolvconf/resolv.conf.d/head si lo que queremos añadir se coloca antes de lo generado por resolvconf, o en el fichero /etc/resolvconf/resolv.conf.d/tail para añadirlo al final del fichero.

Seguir leyendo...

Configuración de SPF, DKIM y DMARC para asegurar el envío de correos

En el día de hoy, como ya anunciaron hace unas semanas, Google y Yahoo intensifican sus políticas de verificación de protocolos de autenticación para correos electrónicos, con el objetivo de luchar contra el spam.

De tal forma, que estas dos compañías (presumiblemente el resto se irán sumando a estas nuevas políticas), exigirán que todos los correos cumplan con los estándares SPF, DKIM y DMARC. SPF autoriza al servidor que envía tus correos, DKIM garantiza la integridad del mensaje y DMARC indica al receptor qué hacer si alguno de los anteriores no coincide (por ejemplo, rechazarlo o enviarlo a carpeta de spam).

En este artículo, voy a hacer una introducción de cada uno de estos protocolos y cómo los podemos configurar para asegurar que los correos enviados por los servidores de correos que administramos “lleguen a buen puerto”.

SPF

En principio, cualquier máquina tiene la capacidad de enviar mensajes de correo a cualquier destino utilizando cualquier remitente. Esto se diseñó originalmente para permitir el envío de mensajes con diferentes remitentes a través de un mismo servidor de correos. Sin embargo, esta característica del correo electrónico ha sido ampliamente explotada para inundar los servidores de correo con mensajes no deseados y llevar a cabo suplantación de remitentes (email spoofing).

Dada la masiva utilización indebida de esta funcionalidad, se ha generalizado la implementación de medidas complementarias con el fin de reducir al máximo este problema. En la actualidad, la mayoría de los servidores de correo adoptan medidas que implican el rechazo o la clasificación como spam de los mensajes provenientes de servidores que no implementan algún mecanismo adicional de autenticación.

Sender Policy Framework (SPF) es un mecanismo de autenticación que mediante un registro DNS de tipo TXT describe las direcciones IPs y nombres DNS autorizados a enviar correo desde un determinado dominio. Actualmente muchos servidores de correo exigen como mínimo tener un registro SPF para tu correo o en caso contrario los mensajes provenientes de tu servidor se clasifican como spam o se descartan directamente.

Ejemplo de registro SPF:

DOMINIO.    600 IN  TXT "v=spf1 a mx ptr ip4:X.X.X.X/32 ip6:XXXX:XXXX:XXXX::XXXX:XXXX/128 a:nombre_máquina -all"

En definitiva es una lista de direcciones IP que autorizamos el envío del correo de nuestro dominio. Los parámetros significan los siguiente:

  • a: Las direcciones IP declaradas en cualquier registro A de la zona DNS del dominio.
  • mx: IP de la máquina a la que apunta el registro MX del DNS del dominio.
  • ptr: Las direcciones IP declaradas en los registros PTR de nuestra zona de resolución inversa.
  • ip4: Direcciones IPv4.
  • ip6: Direcciones IPv6.

Por ejemplo, si tenemos un dominio example.org y nuestro servidor de correo posee una dirección IP pública 203.0.113.1, el registro DNS podría definirse de la siguiente manera:

dig txt example.org
...
example.org.	0	IN	TXT	"v=spf1 ip4:203.0.113.1  ~all"

Es importante comentar el signo que aparece antes de all, ya que podemos indicarle a los otros servidores lo que deben hacer si reciben correo desde otra dirección o máquina diferente a las que aparecen en el registro anterior:

  • -: Descartar el mensaje.
  • ~: Clasificarlo como spam.
  • ?: Aceptar el mensaje (sería como no usar SPF).

De esta forma el correo que enviemos desde nuestra máquina, pasará los filtros SPF en destino y la mayoría de nuestros correos llegarán a destino con poca probabilidad de que se clasifiquen como spam.

Seguir leyendo...

Cursos sobre OpenShift v4

openshift

En esta entrada del bloque os dejo los contenidos de dos cursos que he imparte en mayo de este año en la plataforma de aprendizaje OpenWebinars sobre OpenShift v4.

Aprende Kubernetes con OpenShift v4

En esta formación aprenderemos los recursos principales de Kubernetes usando OpenShift v4, y hacia la parte final, desplegaremos una aplicación completa para poner en práctica todo lo aprendido.

Curso: Aprende Kubernetes con OpenShift v4

OpenShift v4 como PaaS

En esta formación vamos a aprender las distintas estrategias de despliegues de aplicaciones que nos ofrece OpenShift v4, que nos permite enmarcar esta herramienta en un servicio PaaS.

Curso: OpenShift v4 como PaaS

Seguir leyendo...
cc

Licencia

Licencia: Puedes copiar y modificar todos los contenidos, pero siempre respetando los términos de la licencia CC-BY-SA.

Ver