Publicado el

Cómo configurar un registro SPF

emailSPF, o Sender Policy Framework, es un estándar usado para verificar que los correos electrónicos enviados desde un determinado dominio, proceden de servidores de correo autorizados para dicho dominio.

Es decir, con telnet (u otros métodos), podríamos enviar un mail usando cualquier dirección de correo electrónico como origen. Así por ejemplo, yo podría enviar un mail haciéndome pasar por [email protected], o [email protected]. Aquí (y en muchos otros sitios) explican cómo.

El registro SPF, pues, sirve para ayudar a determinar a un servidor de correo, si el mail que acaba de recibir ha de descartarse o entregarse en el inbox.

Continuar leyendo «Cómo configurar un registro SPF»

Publicado el

RDNS PTR IPv6 en AWS Route53

Cloud Amazon Route53Título duro y críptico donde los haya, pero si estás aquí es por una razón: quieres saber cómo configurar una zona Reverse DNS donde crear tus registros PTR de tus direcciones IPv6 con Amazon Route 53.

Primero de todo, para poder gestionar tú mismo los registros PTR, deberás confirmar que te pueden delegar la gestión del RDNS. Para ello, deberás confirmar con tu ISP que efectivamente, te puede delegar la gestión de los RDNS de tu rango de IPs públicas, ya que en otro caso, no podrás auto-gestionarte el RDNS.

Reverse Zone Name

Tras confirmar que el ISP nos podrá delegar la gestión del RDNS, lo primero que haremos, será pedirle a nuestro ISP que nos dé el nombre de la reverse zone que deberemos crear. El nombre de la zona, será la parte fija de nuestra IP pública, al revés, acabada en «.ip6.arpa». Ejemplo:

IPv6 range: 1234:5678:9ABC::/48
Reverse zone name: C.B.A.9.8.7.6.5.4.3.2.1.ip6.arpa

Con estos datos ya podremos entrar en el panel de AWS para la gestión de Route53.

Continuar leyendo «RDNS PTR IPv6 en AWS Route53»

Publicado el

System DNS Cache en Linux

cache DNSEste fin de semana casi nos cargamos a un pobre servidor DNS por un exceso de consultas al realizar un envío de varios miles de mails. En algunos servidores Linux, no hay una caché DNS a nivel de sistema operativo, y por tanto, cada envío de mail requiere de su correspondiente resolución DNS, a pesar de que se estén enviando 1.000.000 de mails todos al mismo dominio @miempresa.com. [fuente, otra fuente, y más fuentes].

Ésto  lo podemos comprobar, por ejemplo desde mi portátil con Fedora, monitorizando con tcpdump las peticiones DNS y ejecutando en paralelo un «ping google.com»:

[root@AdriPC sh]# tcpdump -vvv -s 0 -l port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:44:09.480324 IP (tos 0x0, ttl 64, id 14684, offset 0, flags [DF], proto UDP (17), length 59)
AdriIPC.36193 > google-public-dns-a.google.com.domain: [udp sum ok] 14321+ A? www.google.es. (31)
16:44:09.509206 IP (tos 0x0, ttl 64, id 14713, offset 0, flags [DF], proto UDP (17), length 66)
AdriIPC.51444 > google-public-dns-a.google.com.domain: [udp sum ok] 64003+ PTR? 8.8.8.8.in-addr.arpa. (38)
16:44:09.520190 IP (tos 0x0, ttl 48, id 61176, offset 0, flags [none], proto UDP (17), length 91)
google-public-dns-a.google.com.domain > AdriIPC.36193: [udp sum ok] 14321 q: A? www.google.es. 2/0/0 www.google.es. [3m28s] A 173.194.34.247, www.google.es. [3m28s] A 173.194.34.248 (63)
16:44:09.533873 IP (tos 0x0, ttl 64, id 14738, offset 0, flags [DF], proto UDP (17), length 73)
AdriIPC.50336 > google-public-dns-a.google.com.domain: [udp sum ok] 27187+ PTR? 247.34.194.173.in-addr.arpa. (45)

[…]

Si ejecutamos «ping google.com» una segunda vez, veremos como vuelve a capturarse la consulta DNS mediante tcpdump, confirmando así que no hay ningún tipo de caché DNS.

En la mayoría de escenarios, no necesitaremos una caché DNS, pero si tenemos un servidor que ofrece un servicio que hace un uso intensivo de resolución de nombres, seguramente nos merezca la pena buscar una solución.

Continuar leyendo «System DNS Cache en Linux»

Publicado el

Reenviadores en DNS Server

JediEsta semana hemos estado montando un servidor de Directorio Activo, para un nuevo dominio en una red. Tecnología punta: Windows 2000 server.

Durante la instalación de Directorio Activo, se nos da la posibilidad de instalar también el servicio de Servidor DNS en la misma máquina, que es lo habitual, y es lo que hemos hecho.

Sin embargo, al acabar las instalaciones y empezar con las configuraciones, hemos querido añadir un reenviador al servidor DNS, para que pueda resolver cualquier dirección de Internet, y que no sólo se encargue de la resolución de nombres de la red local (léase, de los nombres definidos dentro de la zona o zonas configuradas en el servidor DNS).

El problema, es que nos hemos encontrado, tanto la sección de reenviadores, como la sección de «root hints», deshabilitadas, puesto que además de la zona con el dominio definido, aparecía la zona raíz (.) en el propio servidor DNS. Básicamente, esto ocurre cuando al instalar un servidor DNS, éste no encuentra ningún otro servidor DNS. En ese caso, se configura a sí mismo como servidor raíz.

Símplemente eliminando la zona raíz (.), y refrescando (F5), se consigue habilitar la sección de reenviadores, y además se listan de forma automática los «root hints».

Fuente: http://www.petri.co.il/no_forwarding_or_root_hints_on_dns_server.htm

Flickr! Foto por PhillipWest