Solución 1:
jeje, voté a favor de la respuesta anterior antes de arreglarme un poco.
Correcto, entonces, si editas tu named.conf
y agrega lo siguiente:
zone "newdomain.com" {
type forward;
forward only;
forwarders { 22.22.22.22; };
};
ahora no podrá realizar búsquedas inversas fácilmente, tendrá que modificar la siguiente declaración de zona para que tenga sentido para las direcciones IP del dominio (esto era originalmente un reverso para 192.168.80.0/24).
zone "80.168.192.in-addr.arpa" {
type forward;
forward only;
forwarders { 22.22.22.22; };
};
Después de realizar los cambios, debe
-
Comprueba que no hayas alterado los archivos de configuración:
named-checkconf
-
Dile a bind que recargue su configuración:
rndc reload
(mucho preferible a/etc/init.d/bind reload
)
Tenga en cuenta que esto devolverá respuestas no autorizadas para el dominio. La forma de evitar esto (y de ofrecer un mejor almacenamiento en caché local en caso de que el DNS remoto sea problemático) sería actuar como esclavo de la zona.
editado para agregar el forward only;
declaración. esto hará que la consulta falle después de probar los servidores especificados en los reenviadores, en lugar de fallar y luego intentar una búsqueda estándar. También editado para cambiar /etc/init.d/bind recargar a rndc reload
después de los consejos en los comentarios.
Solución 2:
Si está intentando optimizar y 22.22.22.22 es la autenticación para esa zona, también puede usar una zona auxiliar:
zone "newdomain.com" {
type stub;
masters { 22.22.22.22 };
};
Esto hace algo ligeramente diferente al reenvío. Consultará el servidor 22.22.22.22 en busca de registros NS y los mantendrá en el caché en todo momento. Esto hará casi lo mismo, pero si también se incluyera otro host NS (digamos, 33.33.33.33), su servidor lo aprendería y lo usaría también.
Creo que una zona de código auxiliar aquí es una mejor opción que el reenvío condicional.
Solución 3:
¿Puedes operar como esclavo de newdomain.com? es decir, ¿realizar una transferencia completa?