Claves TSIG en su servidor DNS primario: BIND, PowerDNS, NSD y Knot
Qué necesita
Una clave TSIG firma cada transferencia de zona entre su servidor primario y nuestros secundarios. Su primario autentica entonces nuestros servidores por la clave, no por sus direcciones IP.
Necesita tres cosas del panel de SecondDNS:
1. La clave. Créela en Configuración › DNS. El diálogo muestra el nombre de la clave, el algoritmo (hmac-sha256 o hmac-sha512) y el secreto. El secreto se muestra una sola vez: cópielo antes de cerrar el diálogo. Si lo pierde, regenere la clave. 2. Las direcciones de nuestros servidores para NOTIFY. Aparecen en la página Añadir zona y en el diálogo de la clave. Los ejemplos usan 192.0.2.10 y 2001:db8::10; sustitúyalas por las suyas. 3. El nombre de la clave, por ejemplo `user_ab12cd34-primary`. Es el nombre de su cuenta más la etiqueta que eligió.
En cada ejemplo sustituya `SECRET_FROM_DASHBOARD` por su secreto y `example.com` por su zona. Use el algoritmo con el que se creó la clave.
¿Es nuevo en DNS secundario? Empiece por Cómo configurar un servidor DNS secundario y vuelva aquí para firmar las transferencias.
Cómo funciona TSIG
TSIG (Transaction Signature, RFC 8945, que sustituyó a RFC 2845) añade un registro de firma a un mensaje DNS. Ambos lados tienen el mismo secreto. El remitente calcula un HMAC sobre el mensaje, el nombre de la clave, el algoritmo y el momento de la firma; el receptor calcula el mismo HMAC con su copia del secreto y compara.
En una transferencia de zona esto ocurre en ambos sentidos. Nuestro secundario firma su solicitud AXFR o IXFR; su primario comprueba la firma y, si la clave está permitida para la zona, envía la zona con su propia firma, que a su vez comprueba nuestro lado. Una transferencia que no supera alguna de las comprobaciones se descarta.
En la práctica importan tres propiedades:
– El secreto nunca viaja. Solo viaja la firma. Quien capture el tráfico ve los datos de la zona, pero no puede generar una solicitud válida. – La hora forma parte de la firma. Cada firma lleva el momento de la firma y una diferencia de reloj permitida (normalmente 300 segundos). Una solicitud fuera de esa ventana se rechaza con BADTIME, por eso ambos servidores necesitan un reloj correcto. – TSIG autentica, no cifra. La zona sigue cruzando la red en texto claro. Si lo sensible es el propio contenido, TSIG no le servirá: solo decide quién puede obtener la zona.
Cómo funcionan AXFR e IXFR en sí, y cómo los dispara NOTIFY, se explica en Entendiendo las transferencias de zona AXFR.
TSIG o lista de IP permitidas
Sin clave, su primario decide por la dirección de origen: las IP de nuestros servidores están en `allow-transfer`, `allow-axfr-ips`, `provide-xfr` o una ACL, y cualquier otra dirección se rechaza. Funciona y sigue siendo un valor predeterminado razonable, pero ata su configuración a nuestras direcciones.
Una clave elimina ese vínculo. Su primario confía en quien presenta la clave, así que un cambio en nuestras direcciones, una fuente de transferencia adicional por nuestra parte o el traslado de su zona a otra de nuestras ubicaciones no le obliga a editar el primario. Además separa a los clientes que comparten un primario: cada cuenta de SecondDNS tiene sus propias claves, y la clave de una cuenta no puede obtener las zonas de otra.
También puede combinar ambas cosas. Mantenga nuestras direcciones en la ACL y exija la clave. En NSD y Knot indique nuestras direcciones en lugar de `0.0.0.0/0` junto con la clave. En BIND una lista de coincidencias se cumple con cualquier elemento, así que direcciones y clave juntas en `allow-transfer` significan dirección o clave; para exigir ambas, use la forma anidada:
allow-transfer { !{ !{ 192.0.2.10; 2001:db8::10; }; any; }; key "user_ab12cd34-primary"; };Entonces una transferencia necesita el origen correcto y la clave correcta.
Elección del algoritmo
Las claves de SecondDNS usan hmac-sha256 o hmac-sha512. Ambos son compatibles con todas las versiones actuales de BIND, PowerDNS, NSD y Knot DNS.
Elija hmac-sha256 salvo que tenga un motivo para no hacerlo: es la opción habitual en documentación y ejemplos, y su secreto de 32 bytes es lo bastante corto para pegarlo sin saltos de línea. hmac-sha512 usa un secreto de 64 bytes; elíjalo cuando una política de su parte lo exija. Los algoritmos antiguos como hmac-md5 y hmac-sha1 no se ofrecen.
El algoritmo queda fijado al crear la clave. Para cambiarlo, cree una clave nueva con el otro algoritmo, selecciónela para sus zonas y elimine la antigua.
La longitud del secreto depende del algoritmo: 32 bytes para hmac-sha256 y 64 bytes para hmac-sha512, es decir, 44 y 88 caracteres en base64. Copie el secreto completo, incluido cualquier `=` del final: sin ellos su primario rechaza la clave o calcula otra firma, y la transferencia termina con BADSIG.
BIND
Añada la clave y permita las transferencias firmadas con ella. Son los mismos bloques que muestra el panel:
key "user_ab12cd34-primary" {
algorithm hmac-sha256;
secret "SECRET_FROM_DASHBOARD";
};
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
allow-transfer { key "user_ab12cd34-primary"; };
also-notify { 192.0.2.10; 2001:db8::10; };
};Con la clave en `allow-transfer` no necesita nuestras direcciones IP ahí. Mantenga `also-notify`: los mensajes NOTIFY no se firman y los aceptamos desde la dirección de su primario.
Compruebe la configuración y aplíquela:
named-checkconf && rndc reconfigPor qué NOTIFY decide lo rápido que nos llegan los cambios: sincronización de zonas con NOTIFY.
PowerDNS
Importe la clave, permítale transferir la zona y envíe NOTIFY a nuestros servidores:
# PowerDNS 4.x
pdnsutil import-tsig-key user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil activate-tsig-key example.com user_ab12cd34-primary primary
pdnsutil set-meta example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10
# PowerDNS 5.x
pdnsutil tsigkey import user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil tsigkey activate example.com user_ab12cd34-primary primary
pdnsutil metadata set example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10La zona debe ser de tipo `primary` (o `native` con su propia configuración de NOTIFY). `activate-tsig-key … primary` (`tsigkey activate` en 5.x) añade la clave a los metadatos `TSIG-ALLOW-AXFR` de la zona. PowerDNS da acceso a la zona a una solicitud firmada con una clave de `TSIG-ALLOW-AXFR` aunque la dirección no esté en `allow-axfr-ips`.
NSD
Defina la clave en `nsd.conf` y permita las transferencias solo con ella:
key:
name: "user_ab12cd34-primary"
algorithm: hmac-sha256
secret: "SECRET_FROM_DASHBOARD"
zone:
name: "example.com"
zonefile: "example.com.zone"
provide-xfr: 0.0.0.0/0 user_ab12cd34-primary
provide-xfr: ::0/0 user_ab12cd34-primary
notify: 192.0.2.10 NOKEY
notify: 2001:db8::10 NOKEY`provide-xfr` con `0.0.0.0/0` y `::0/0` significa: desde cualquier dirección, pero solo con esta clave. Para comprobar dirección y clave, indique en su lugar nuestras direcciones. NOTIFY va a nuestras direcciones sin firma (`NOKEY`).
Compruebe y aplique:
nsd-checkconf /etc/nsd/nsd.conf && nsd-control reconfigKnot DNS
Defina la clave, una ACL que permita con ella las transferencias salientes y nuestros servidores como destino de NOTIFY:
key:
- id: user_ab12cd34-primary
algorithm: hmac-sha256
secret: SECRET_FROM_DASHBOARD
remote:
- id: seconddns
address: [192.0.2.10, 2001:db8::10]
acl:
- id: seconddns_transfer
key: user_ab12cd34-primary
action: transfer
zone:
- domain: example.com
acl: seconddns_transfer
notify: seconddnsUna ACL solo con `key` admite solicitudes firmadas con esa clave desde cualquier dirección. Añada `address` a la ACL para exigir ambas cosas.
Compruebe y aplique:
knotc conf-check && knotc reloadCompruebe la clave antes de añadir la zona
Pida la zona a su primario con la clave, desde cualquier máquina que lo alcance por el puerto TCP 53:
dig @PRIMARY_IP example.com AXFR -y hmac-sha256:user_ab12cd34-primary:SECRET_FROM_DASHBOARDUn listado completo de la zona significa que la clave y el permiso son correctos. `BADKEY` significa que su primario no conoce ninguna clave con ese nombre; `BADSIG`, que el secreto o el algoritmo no coinciden. `Transfer failed` con REFUSED y sin error TSIG significa que la clave es válida pero no está permitida para esta zona.
Confirme que la transferencia fue firmada
Una vez añadida la zona con la clave, su primario registra cada transferencia junto con la clave que la firmó. En BIND una transferencia firmada tiene este aspecto:
client @0x… 192.0.2.10#43001/key user_ab12cd34-primary (example.com): transfer of 'example.com/IN': AXFR started: TSIG user_ab12cd34-primary (serial 2026101101)El nombre de clave después de `TSIG` es el que usó nuestro servidor. Una transferencia registrada sin nombre de clave se permitió por dirección, no por la clave: compruebe que la zona tiene de verdad la clave seleccionada en el panel y quite nuestras direcciones de la ACL si quiere que la clave sea obligatoria.
En PowerDNS, NSD y Knot DNS busque el nombre de la zona en el registro en el momento de la transferencia. Por nuestra parte, el panel muestra el serial de la zona y el número de registros tras la primera transferencia correcta.
Seleccione la clave en el panel
Al añadir un dominio, elija la clave en el campo Clave TSIG. Su clave predeterminada, si la ha definido, viene seleccionada; con Ninguna la zona se transfiere sin firma. Para una zona existente, abra su diálogo de edición y cambie la clave allí.
Nuestros servidores firman entonces con la clave sus solicitudes de transferencia para la zona. Una clave llega a nuestros servidores solo mientras una zona la usa.
Regenerar una clave sustituye el secreto de inmediato. Las zonas que la usan dejan de sincronizarse hasta que su primario tenga el nuevo secreto, así que actualice el primario justo después.
Rotación de una clave
Rote una clave cuando el secreto pueda haberse expuesto, cuando se vaya alguien que tenía acceso al primario o periódicamente si su política lo exige.
Para que la interrupción sea lo más breve posible:
1. Abra la configuración de su primario para tener el cambio listo. 2. En Configuración › DNS, elija Regenerar en la clave. El diálogo indica cuántas zonas la usan. Copie el secreto nuevo del diálogo que aparece a continuación. 3. Sustituya el secreto en su primario y recárguelo de inmediato. 4. Compruébelo con el comando `dig -y` de arriba y el secreto nuevo.
Entre los pasos 2 y 3 nuestros servidores ya firman con el secreto nuevo, así que las transferencias de esas zonas fallan hasta que su primario lo tenga. Las zonas siguen respondiendo desde nuestra última copia; solo los cambios dejan de llegar hasta entonces. Si no puede permitirse ninguna interrupción, cree una segunda clave, añádala al primario junto a la primera, selecciónela para las zonas en el panel y elimine la antigua cuando ya nada la use.
Solución de problemas
BADKEY: su primario no conoce ninguna clave con ese nombre. Compare el nombre de su configuración con el del panel, incluido el prefijo de la cuenta.
BADSIG: el secreto o el algoritmo no coinciden. Copie de nuevo el secreto, o regenere la clave y actualice el primario.
BADTIME: las firmas TSIG llevan una marca de tiempo y se rechazan si los relojes difieren más de unos minutos. Asegúrese de que su primario sincroniza la hora por NTP.
Los cambios llegan tarde: NOTIFY no llega a nuestros servidores. Compare `also-notify`, `ALSO-NOTIFY` o `notify` con nuestras direcciones y que los puertos UDP y TCP 53 hacia ellas estén abiertos.
Transferencia rechazada aunque la clave es correcta: la clave no está permitida para esta zona. Revise `allow-transfer`, `TSIG-ALLOW-AXFR`, `provide-xfr` o la ACL en la propia zona, no solo en la configuración global.
Preguntas frecuentes
¿Puedo usar una clave para varias zonas? Sí. Seleccione la misma clave para cada zona en el panel y permítala en cada zona de su primario. Su plan fija cuántas claves puede tener una cuenta.
¿Puedo usar una clave generada por mí? No. SecondDNS genera la clave y muestra el secreto una vez, así que el secreto nunca nos llega desde fuera y solo se guarda cifrado.
¿Cambia algo TSIG para IPv6? No. La clave no depende de la familia de direcciones. Permita la clave y, si también restringe por dirección, indique nuestras direcciones IPv6 además de las IPv4.
¿Se firma NOTIFY? No. Su primario envía NOTIFY sin firma y lo aceptamos desde la dirección de su primario. Un NOTIFY solo nos pide comprobar el serial; la transferencia que sigue va firmada.
¿Se firman también las transferencias incrementales (IXFR)? Sí. La clave se aplica a las solicitudes AXFR e IXFR de la zona.
¿Qué pasa si elimino la clave en mi primario pero la mantengo seleccionada en el panel? Las transferencias empiezan a fallar con BADKEY. La zona sigue respondiendo desde nuestra última copia hasta que caduque según el valor expire del SOA (qué significan los temporizadores del SOA), así que corrija la configuración a tiempo o seleccione Ninguna para la zona.
¿Puedo eliminar una clave que aún usan zonas? No. El panel muestra qué zonas la usan; seleccione primero para ellas otra clave o Ninguna.
¿Necesito abrir otros puertos además del 53? No. Las transferencias usan el puerto TCP 53 y NOTIFY el puerto UDP 53. TSIG no añade puertos: la firma viaja dentro del mismo mensaje DNS.
¿Puedo ver qué claves usan mis zonas? Sí. En Configuración › DNS cada clave muestra cuántas zonas la usan, y cada tarjeta de zona muestra el nombre de su clave junto a la dirección del primario.