Algo que tenía pendiente desde hace mucho tiempo y que acabo de completar. Añado también alguna cosa sobre registros SRV.
No tengo muchos servidores DNS gestionados directamente por mí pero los que hay son muy importantes. Uno es en mi lugar de trabajo para el dominio interno empresa.net y el otro es para mi experimento de IP dinámicas en balteus.net.
Ambos usan el programa Bind (versión 9) con el que estoy bastante familiarizado y que funciona muy correctamente. También es cierto que la configuración puede ser farragosa, y que siempre tengo que consultar documentación y foros, pero una vez que los has puesto en marcha son tan eficientes como se espera de un programa de larga trayectoria.
No voy a poner aquí todos los detalles técnicos que para eso están las referencias más abajo. Tan sólo anotar lo siguiente:
- Como mi red interna tiene como máscara 24 bits (192.168.100.0/24) el archivo es db.192.168.100 y las direcciones IP resultantes son más sencillas.
- Siguiendo recomendaciones leídas en Zytrax estoy añadiendo registros para los registros CNAME porque por lo visto si no están es posible que fallen en algunas búsquedas inversas como las efectuadas en comprobaciones de envío de correo.
Algunos ejemplos educativos serían la zona directa:
; Servidor ERP con sus alias correspondientes
erp IN A 192.168.100.9
test IN CNAME erp
app IN CNAME erp
replica IN CNAME erp
y la zona inversa correspondiente:
9 IN PTR erp.empresa.net.
9 IN PTR test.empresa.net.
9 IN PTR app.empresa.net.
9 IN PTR replica.empresa.net.Y para incluir dicho archivo en la configuración de bind la situamos de la siguiente forma:
zone "100.168.192.IN-ADDR.ARPA" in {
type master;
allow-update { key rndc-key; };
allow-transfer { 192.168.100.3; 192.168.100.7; };
file "/etc/bind/db.192.168.100";
};Además de esto es necesario tener en cuenta que en los servidores esclavos también hay que declarar la zona inversa.
zone "100.168.192.in-addr.arpa" {
type slave;
masters { 192.168.100.1; };
file "/etc/bind/db.192.168.100";
allow-transfer { none; };
};Y ya se pueden hacer búsquedas en ellos sin el menor de los problemas:
$ dig @ns2.empresa.net -x 192.168.100.9
...
;; ANSWER SECTION:
9.100.168.192.IN-ADDR.ARPA. 604800 IN PTR erp.empresa.net.
9.100.168.192.IN-ADDR.ARPA. 604800 IN PTR test.empresa.net.
9.100.168.192.IN-ADDR.ARPA. 604800 IN PTR app.empresa.net.
9.100.168.192.IN-ADDR.ARPA. 604800 IN PTR replica.empresa.net.
...
$Los registros SRV
Este tipo de registros están definidos en el RFC2782 y su propósito es facilitar búsquedas de servicios concretos. En el texto se usa mucho como ejemplo el servicio de directorio LDAP, pero también avisan que es justamente un ejemplo y que es mejor mirar directamente en la documentación de aquello que se quiere registrar no vayamos a encontrarnos con cambios inesperados.
Tiene más miga de la que parece pero todo se reduce a una definición de registro que proporciona la información precisa sobre dónde y cómo conectarse a un servicio.
El registro SRV tiene la siguiente estructura:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Lo más destacable es que tanto el nombre del servicio como el del protocolo van precedidos de un guión bajo para no colisionar con nombres reales. No es raro encontrar una máquina llamada imap.empresa.net por lo que se curan en salud. El protocolo igual y además no está limitado a tcp o udp. Es algo que dejan abierto y me parece muy sensato.
La prioridad y el peso forman parte de un mecanismo para seleccionar el servidor adecuado en el caso de que existan varios. Como comentan algunos programas se conforman con uno y otros esperan hallar más y siguen un orden concreto para elegir con el que se quedan. En mi caso con uno voy que me mato pero está bien tenerlo en cuenta para cuando llegue a construir mi servidor de correo secundario.
La información final incluye el nombre del servidor (no un alias insisten) y un puerto con el que efectuar la conexión. Si el nombre del servidor apunta al local con el carácter punto (.) significa que no hay nadie al otro lado. El dominio no dispone de ese servicio.
Lo del puerto de conexión es una forma de independizarse de la obligatoria consulta al archivo /etc/services y dotar de mayor movilidad a los servicios. A mí me parece una buena idea y como comentan al final del documento no están añadiendo problemas de seguridad nuevos. Si el programa que responde en un puerto tiene agujeros los va a tener igualmente en otro.
Un ejemplo que aún no he verificado es el que muestro más abajo:
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.De manera que el servicio foobar está disponible en dos máquinas, una lenta y otra rápida, y se pretende con el parámetro peso que se realicen más conexiones con la rápida que con la lenta.
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .El archivo de zona termina con una declaración tajante: no hay más servicios de ningún tipo anunciados en el dominio.
Autoconfiguración de clientes de correo
No he podido evitar visto lo anterior alcanzar este punto. Resulta que configurar tu dominio para que anuncie los diferentes servicios está muy bien y puede ser de gran ayuda pero se queda corto en algunos casos.
El del correo electrónico es uno de ellos. Para empezar porque existen dos consultas mínimas que realizar cuando se está añadiendo una cuenta al programa: una para saber dónde leer el correo (POP3 o IMAP) y otro para saber por dónde enviarlo (SMTP). Con los registros SRV tienes dos datos: dirección IP y puerto. Pero para el correo se necesita más.
Un nombre de usuario que no tiene que coincidir con la dirección de correo por mucho que Google y compañía se empeñen en ello. Si la conexión está cifrada o no y la forma de cifrarla (SSL o TLS pongamos) además de si las contraseñas están en texto plano o a su vez han sido cifradas.
Son bastantes parámetros y combinaciones para los que el DNS no se aplica. No es que no se pueda, es que no tiene sentido embrollarlo más. Organizaciones como Mozilla han creado mecanismos para que el usuario (y el administrador de correo) lo tenga fácil y sólo necesite indicar su dirección de correo y su contraseña. El resto se consulta al ISP que devuelve la información en un documento XML, flexible y completo. Tanto que incluso proporciona información como para pedir más datos al usuario.
En las referencias está el proceso explicado con todo detalle. Aquí sólo voy a anotar lo que me ha parecido más relacionado.
Con la dirección de correo del usuario en la mano Thunderbird efectúa una búsqueda primero en dos lugares: la base de datos ISPDB que alojan ellos y donde registran la información de un enorme número de ISP y en el dominio del correo.
El primer lugar, ISPDB, está abierto al todo el mudno en la siguiente dirección https://autoconfig.thunderbird.net/v1.1/ y se organiza con un archivo XML por cada nombre de ISP. Por ejemplo el de gandi.net, donde tengo registrados todos mis dominios, está aquí.
El segundo lugar es dependiente del servidor de correo. Primero se intenta localizar en el DNS el nombre autoconfig y si se encuentra se prueba una petición del tipo https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=fred@example.com (ojo, conexión cifrada).
Si no da resultado se intenta hacer lo mismo empleando los famosos well-known services que tanto juego dan y tan poco se conocen. La petición es entonces del siguiente tipo: http://example.com/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=fred@example.com
En cualquier de los dos casos se espera recibir un archivo XML que describa todas las formas admitidas de obtención y envío de correo para esa cuenta. Incluye aspectos tan chulos como
- Varios servidores para recepción y para envío de correo con las diferentes opciones de protocolo, cifrado y contraseña usada. Muy práctico para dar más cabida a programas relativamente antiguos.
- Empleo de marcas de sustitución de valores como la dirección de correo completa, sólo la parte local o sólo la parte del dominio (fred@example.com, fred o example.com).
- Documentación de ayuda para el usuario como URL.
- Campos para entrada de datos de usuario. No implementado aún del todo pero muy interesante para construir conexiones más complejas como las que se pueden emplear en el protocolo IMAP (carpetas especiales, subcarpetas y demás).
No he buscado aún algún programa que automatice la creación de estos archivos empleando un directorio LDAP porque ya no me da la vida, pero lo anoto como guinda al pastel de la configuración de correo en mis dominios.
[…] tiene relación como explico en mi otro blog y, encima, me ha estimulado para crear un paquete específico que pueda aplicar en todos los […]