Este post aborda muchos aspectos del proceso de instalación de un sistema de servidores DNS basado en PowerDNS. He tenido que dividirlo en varias partes debido a su extensión.

También contiene el código necesario para migrar una base de datos de un sistema de MyDNS al entorno de PowerDNS.

Todo el código que aquí se publica (disponible también en Github) ha sido desarrollado, pacientemente, por mí, es libre pero úsalo con responsabilidad.

Esta primera parte explica el por qué se ha elegido PowerDNS y no otro, así como una descripción del esquema de conexiones que se va a usar para toda la entrada.

1. PowerDNS

1.1. Introducción

Hace ya algunos meses estuve presente en una conversación en la que se habló de migrar MyDNS a otro tipo Servicio de DNS, como por ejemplo PowerDNS, y tuve un primer contacto en una pequeña tarea que me asignaron en otro sitio distinto del primero, pero el objetivo principal de esta tarea no era PowerDNS, así que casi no cuenta.

El tema de los servidores DNS para mí comenzaba por ISC BIND y terminaba en la cola con el Servidor DN$ de window$, pasando por DNSMASQ y poco más. De hecho, incluso este proyecto lo empecé diciendo – ¿y por qué no usamos BIND que es el servicio de DNS de toda la vida? – …..ay… hombre de poca fe.

Estuve probando algunos third-party plugins para BIND con backend LDAP como gestor de las zonas, ya que el motivo de este, llamémoslo pretenciosamente, Manual, esta vez sí ha venido de querer reemplazar un servicio en producción MyDNS, y ya que nos ponemos, lo hacemos bien y lo mejoramos.

Después mucho pelearme con el servidor LDAP para que se tragara los esquemas de zonas de BIND tuve que desistir por muchos motivos que aquí no vienen al caso, simplifiquemos y digamos que simplemente se quedaba muy corto para las funcionalidades que necesitábamos, aunque me ha venido bien porque he repasado muchos conceptos que tenía muy olvidados de LDAP.

Finalmente opté por usar PowerDNS, muy a mi pesar, no obstante me he llevado una grata sorpresa, tan grata que he quitado el servidor DDNS BIND (no es una errata, mi BIND recibe actualizaciones de ISC DHCP) que tenía en casa y he puesto este cacharro.

Posterior al montaje inicial con backend de PostgreSQL, instalé PowerAdmin para la gestión de zonas vía aplicación Web.

La interfaz PowerAdmin no es que sea la panacea en cuanto a gestión de registros y zonas DNS se refiere, o puede que sí, pero si lo comparamos con el método de ficheros de BIND, SERIALs (yo tenía replicado BIND en modo maestro/esclavo), zonas dinámicas, que antes de editarlas hay que congelarlas (rndc freeze zona), y luego resumirlas (rnd thaw zona), usar un ratito PowerAdmin me hizo pensar – pues no es tanto suplicio editar registros de un servidor DNS.

Es una interfaz áustera pero con funcionalidades lo suficientemente atractivas como para que no echemos en falta otro tipo de interfaces más sofisticadas.

En PowerAdmin podemos gestionar las zonas, incluidos sus registros, de forma completa y además podemos crear plantillas, permisos, roles y tener un buen nivel de ACL’s para los usuarios que usen este servicio.

Como he dicho antes, también tengo en mi pequeño laboratorio doméstico, cuyo alcance es toda la casa, un montaje de 2 servidores ISC DHCP en modo Failover que manejan una zona estática de Ips (sin piscina de asignación) y varias Dinámicas (DDNS RFC2136) (con piscina) que trabajaban a la perfección con ISC BIND, esto no era caprichoso. Los 4 nodos Bare Metal que dispongo los uso a modo de laboratorio y, aunque no sea muy frecuente, necesito apagarlos, por el motivo que sea. Tener 1 único DHCP y un único BIND, hacía que apagar el nodo donde se encontraban fuera casi catastrófico, pues me quedaba sin esos 2 servicios que son esenciales. Así que para hacer la migración, este método de actualización de registros era imprescindible.

PowerDNS tiene este método de actualización de zonas y funciona perfectamente.

También soporta para múltiples backends simultáneos, aunque no lo he configurado, tengo bastantes esperanzas puestas en esta característica..

PowerDNS viene con una utilidad para la consola para la gestión de los registros DNS, ‘pdnsutil’.

No sé cual es el límite superior de esa utilidad, se ve alto, sin embargo sí puedo decir cuál es la Kriptonita de ‘pdnsutil’: no se pueden eliminar registros con un sencillo comando del tipo ‘pdnsutil del-record ejemplo.com www A 1.2.3.4’

No obstante, se pueden usar subterfugios BASH para conseguirlo, que serán muy útiles para el scripting.

Como pista diré que tiene un editor interactivo de zonas el cual se invoca de la siguiente manera ‘pdnsutil edit-zone ejemplo.com’. Este comando abre el editor que tengamos configurado en la variable del entorno $EDITOR y, cuando guardamos y salimos, se hace una comprobación de los cambios realizados, mostrándonos una serie de opciones típicas, a saber: guardar a toda costa, descartar, revertir cambios, …

Esta utilidad interacciona directamente con la base de datos, así que para usarla en cualquier terminal de la red no es necesario tener instalado PowerDNS completamente, solo necesitas la utilidad y el fichero de configuración del Backend o backends con los que vas a trabajar y, por supuesto, los permisos sobre la base de datos que se use en PowerDNS para acceder de forma remota.

Casi terminando, he de decir que cómo no iba a tener una API HTTP, sobre todo ahora que están tan de moda, pues la tiene y muy completa, devolviendo JotaSONS.

En cuanto a los modos de atacar al servidor para editar zonas creo que no me dejo nada atrás, solo me queda decir que usar este servidor DNS hace que la tarea de gestionar las DNS no sea tan pesada como con ISC BIND, sino que además es muy entretenida, más que nada porque ofrece alternativas para casi todos los gustos.

1.2. Productos

PowerDNS es un servicio de DNS que entre las funcionalidades más destacables que ofrece están:

• Servidor Autoritativo, MASTER/SLAVE

• Servidor Recursivo

• Soporte de múltiple backends

• Importación/Exportación de zonas en ficheros de tipo ISC BIND

• API HTTP

• DNSSEC

• DNSDIST, protección frente a ataques DDoS

1.3. Esquema de montaje

El esquema que se va a seguir en esta guía es este:

1.4. Modos de replicación de zonas

Se pueden seguir 2 modos de replicación para la actualización de las zonas.

• • Maestro / Esclavo: Esta es la configuración clásica en la que, cuando se hace una modificación en los registros de la zona, hay que incrementar el SERIAL del SOA para que los esclavos actualicen sus valores..

    • Entre las ventajas que ofrece este modo de operación tenemos que, una vez configurado PowerDNS en este esquema, nos podemos casi olvidar del mantenimiento del esclavo, tan solo basta con ir actualizando los serials de las zonas cuando así haga falta.

    • Desventaja, este tipo de configuración se da que si el maestro está caído no se pueden hacer modificaciones en los registros del esclavo, por tanto, estamos obligados a levantarlo para poder hacer modificaciones en las zonas, aunque el el esclavo respondería con las zonas que tiene en su base de datos. (ESTO NO ES CORRECTO)

  • Replicación Nativa: Tal y como lo describen los propios desarrolladores de PowerDNS, la replicación nativa corre a cargo del Backend SQL de almacenamiento de zonas. Los motores de bases de datos MySQL y Oracle son lo bastante robustos y maduros como para manejar esta situación. Básicamente este modo lo que indica es que no tiene que notificar cambios en las zonas. Cuando se crea un dominio, hay que establecer en la tabla pdns.domains si es NATIVE o MASTER, los dominios que se creen como Nativos no se transferirán a los esclavos.

    • La desventaja de este modelo puede ser la instalación y configuración de la replicación de la base de datos y el posterior mantenimiento de la misma, sobre todo si se cae o pierde la conexión en el clúster de base de datos.

    • La ventaja es que se puede atacar cualquiera de los servidores para la modificación de registros, gracias a la replicación de la base de datos los cambios estarán de forma casi instantánea en todos los servidores del clúster. El servicio de DNS funcionará plenamente siempre y cuando haya 1 servidor levantado.

Como se puede apreciar en el esquema anterior, habrá 2 másters y 1 esclavo, por supuesto que se pueden añadir más esclavos y más maestros o esclavos.

Dado que la base de datos de los maestros se replica íntegra a todos los efectos los maestros son espejos unos de otros.

El motivo por el que he puesto un esclavo es por tener un nodo cuyos servicios para ser levantados no dependan de los servicios de otros nodos. Es más, ese tercer nodo en modo esclavo también funciona en modo Maestro, con lo que si hubiera un desastre se pueden apagar los otros 2 nodos, se cambiarían en la base de datos el tipo de zona de slave a master, y se promocionaría como un maestro en cuestión de segundos.

Un detalle a tener en cuenta, cuando se borra una zona, hay que hacerlo en todas bases de datos de todos los servidores, o bien entrar en todos y hacerlo mediante la utilidad de ‘pdnsutil’.

1.5. Auto Serial

PowerDNS trae configurado por defecto (no he visto dónde poder desactivarla) la opción de autoserial que consiste en poner a ‘0’ el SERIAL del SOA y PowerDNS tomará como serial el valor más alto de la columna ‘change_date’ de la tabla ‘records’ de esa zona en particular.

He creado los triggers necesarios para que esa columna se actualice cuando se inserta o modifica un registro.

1.6. Edición de las zonas

Para crear o editar zonas hay diferentes opciones.

1.6.1. Consola GNU/Linux

En la consola GNU/Linux está la utilidad ‘pdnsutil’. Esta aplicación tiene todas las opciones necesarias para gestionar las zonas, pondré una captura de cómo crear una zona completa a base de comandos desde una consola remota a PowerDNS:

Como caramelo de esta aplicación de consola, ‘pdnsutil‘ tiene un parámetro ‘edit-zone’ que al ser llamado con una zona como argumento abre el editor que tengamos definido en la variable del entorno $EDITOR y se editará la zona al estilo de ISC-BIND.

1.6.2. Web UI

Hay muchas interfaces Web para PowerDNS, he instalado PowerAdmin principalmente porque está escrita en PHP.

Esta interfaz también ofrece la posibilidad de añadir un poco de seguridad extra con un pequeño control de Usuarios y Permisos sobre las zonas, además de plantillas, búsquedas, etc,…

1.6.3. API

Toda la documentación sobre la API se encuentra detalladamente explicada en la documentación Online de PowerDNS aunque al final de este documento podré los comandos básicos de gestión sobre las zonas.

1.6.4. DNSDIST

También existe DNSDIST que actúa como balanceador de carga y ofrece un aceptable nivel de seguridad contra ataques DDoS sobre el servidor DNS.

Aparte de las reglas que ya trae incorporadas DNSDIST es personalizable mediante scripting LUA.

(TODO: instalar DNSDIST)