☰

Bind9: Maestro->Esclavo Notificar IPv6 con respaldo a IPv4

tag-icon • tag-icon bind ipv6 failover
Bind9: Maestro->Esclavo Notificar IPv6 con respaldo a IPv4

Tengo una pequeña configuración de esquema DNS Maestro->Esclavo entre dos máquinas que ejecutan Debian 8 + Bind9 en una pila de IP dual.

Tanto el maestro como el esclavo poseen un IPv4 e IPv6 utilizado por bind, impuesto por los parámetros de configuración listen-on listen-on-v6 transfer-source transfer-source-v6 notify-source notify-source-v6 query-source address query-source-v6 address.

Actualmente mi maestro está configurado para notificar al esclavo como:

notify yes;
also-notify { xxxx:xxxx:xxxx:xxxx::xxx5; x.x.x.5; };

Como mi esclavo tiene en una configuración de zona algo como:

zone "example.dev" {
    type slave;
    masters { xxxx:xxxx:xxxx:xxxx::xxx2; x.x.x.2; };
    file "...";
};

Esta configuración funciona bien, sin embargo, al inspeccionar los archivos de registro (y como esperaba), el maestro notifica al esclavo dos veces sobre cada cambio de zona:

May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from x.x.x.2#52041: zone is up to date
May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from xxxx:xxxx:xxxx:xxxx::xxx2#51347: zone is up to date

Una vez, sobre IPv4 y otra sobre IPv6.

¿Hay alguna manera de decirle al servidor de enlace cuáles xxxx:xxxx:xxxx:xxxx::xxx5 x.x.x.5son efectivamente direcciones para el mismo servidor DNS e intentar notificarlo primero a través de IPv6 y, si falla, volver a intentarlo a través de IPv4? Además, ¿cómo hacer lo mismo en la mastersdeclaración del ungüento?

Gracias.

Respuesta1

No creo que exista una opción de configuración que haga lo que usted solicita. Sin embargo, tampoco creo que las notificaciones dobles sean realmente motivo de preocupación.

Si bien es redundante en esta configuración, la sobrecarga que genera es mínima y, por lo general, no supone ningún problema.

En términos generales, recibir múltiples mensajes de notificación no está fuera de la norma, originalmente principalmente del maestro + otros esclavos, pero ahora también de hosts de doble pila, hasta el punto en que inclusola especificación original esperaba esto:

4.2. Es probable que cada esclavo reciba varias copias de la misma solicitud NOTIFICAR: una del maestro principal y otra de cada uno de los esclavos a medida que ese esclavo transfiere la nueva zona y notifica a sus pares potenciales. El protocolo NOTIFY admite esta multiplicidad al requerir que NOTIFY sea enviado por un esclavo/maestro solo DESPUÉS de haber actualizado SOA RR o haber determinado que no es necesaria ninguna actualización, lo que en la práctica significa después de una transferencia de zona exitosa. Por lo tanto, salvo que se reordene la entrega, la última NOTIFICACIÓN que reciba cualquier esclavo será la que indique el último cambio. Dado que un esclavo siempre solicita SOA y AXFR/IXFR sólo de sus maestros conocidos, tendrá la oportunidad de volver a intentar su CONSULTA para SOA después de que cada uno de sus maestros haya completado cada actualización de zona.

información relacionada