Implementar DNSSEC sobre Linux. Solo resolver

*** POST OBSOLETO ****
*** FAVOR LEER LA VERSION 2 ***

Problema:
Montar un servidor DNS solo como resolver, es decir, sin funcionar como servidor autorizado para ciertas zonas


Que se necesita:
- Servidor Linux
- Bind 9.3 o superior (en mi caso utilicé 9.6)


Alcance
- Vamos a validar todo lo que sea .br
- Vamos a validar todo lo que sea udp53.org

Procedimiento:
1) Instalar bind en un servidor Linux. En mi caso utilizo Mandriva y con un sencillo urpmi bind fue suficiente. Es importante destacar que para que DNSSEC ande se necesita tener instalado openssl y sus librerias. Actualmente la inmensa mayoría de las distribuciones ya viene con openssl

2) En /var/named.conf se necesita:
options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside "." trust-anchor dlv.isc.org.;
};

La primera opción permite dnssec para las zonas autorizadas y la segunda opción para realizar recursividad utilizando DNSSEC. La tercera opción la veremos con detalle más adelante.


3) Es necesario obtener las llaves públicas de los registros .br y udp53.org (que son los dominios que queremos verificar en este momento). Para ello:

[root@localhost etc]# dig br DNSKEY

{...}

br. 21502 IN DNSKEY 257 3 5 AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PM Npyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/ 6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+D P/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=

{...}


[root@localhost etc]# dig udp53.org DNSKEY

{...}

udp53.org. 5882 IN DNSKEY 257 3 5 BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9

{...}

4) Necesitamos las llaves DLV que pueden ser conseguidas en la pagina de la ISC en:
http://ftp.isc.org/www/dlv/dlv.isc.org.key.
Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad. La idea es apoyar al conglomerado de internet en las primeras etapas de DNSSEC en el mundo

5) Vamos a copiar esas llaves obtenidas en el archivo named.conf bajo la sección trusted-keys (si no existe dicha sección en el archivo la crearemos). Por ejemplo

trusted-keys {
"br." 257 3 5
"AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJB
NmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPq
Xr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1N
GbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hN
x94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=";

"dlv.isc.org." 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";

"udp53.org." 257 3 5 "BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9";

};

6) Listo!!., reiniciar el servidor named. Por ejmplo:
/etc/init.d/named restart (o con rndc, como tu desees)

Revisar que se encuentre funcionando bien

La mejor opción es utilizar el famoso comando dig y chequear el flag AD en al respuesta. Por ejemplo:

RESPUESTA SIN DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43771 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5



RESPUESTA CON DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1063 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1


Más información:
* www.isc.org/files/DNSSEC_in_6_minutes.pdf
* http://registro.br/info/dnssec.html

Problemas con Postfix dsn= 4.4.2

En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.

El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:

dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)

dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)

Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.

Intente disminuir el MTU de la interfaz eth0:

debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1000 Metric:1

Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.

Capaz era problema se relacionaba con el MTU discovery

"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"

Luego de volver a correr "mailq -q", seguia dando el mismo error.


Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.

"debian:/home/xxxx# tcpdump -i eth0 port 25"

Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).

Comparte con ustedes lo que vi en Wireshark


Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.

Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.


debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

debian:/home/xxxx# ethtool --offload eth0 tx off

y luego

debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off


Al hacer esto, los correos empezaron a salir :)....

Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;

"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."

Mas detallado:

"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."