☰

Cómo reenviar una solicitud de DNS para una zona local a un DNS externo cuando no coincide localmente (BIND9)

tag-icon • tag-icon domain-name-system bind
Cómo reenviar una solicitud de DNS para una zona local a un DNS externo cuando no coincide localmente (BIND9)

Tengo un dominio example.comy uso Azure DNS para resolver todos los nombres de host que deberían ser visibles desde Internet. Lo tengo definido mail.example.compara señalar 198.51.100.123y lo pueden resolver clientes externos sin ningún problema.

También se example.comusa en mi LAN y el uso de bind resuelve todas las direcciones IP locales, lo que funciona bien para los nombres de host locales. Mi servidor DHCP también sabe cómo solucionar esto y actualiza los archivos de zona correctamente. Todas las solicitudes de DNS para otras zonas se reenvían a Cloudflare DNS.

Me gustaría que mi servidor usara el servidor de nombres local y, si no puede encontrar una entrada en el archivo de zona local, debería comunicarse con el servidor de Azure y verificarlo. Cuando agrego las siguientes entradas a mi archivo de zona, funciona para estos nombres de host:

external-dns            A       1.1.1.1
vpn                     NS      external-dns
www                     NS      external-dns
ftp                     NS      external-dns

Los comodines ya no funcionan en Bind9, por lo que no puedo usarlos * NS external-dns. ¿Hay alguna otra manera de lograr esto?

Respuesta1

Utilice una response-policyzona en lugar de una zona maestra paraexample.com

Al intentar resolver un nombre de host, bind buscará response-policyprimero en el archivo de zona y, si no encuentra la respuesta, continuará buscando.

A continuación se muestra una configuración de ejemplo:

options {
    # Your normal options
    response-policy { zone "local_example_com"; };
};
zone "local_example_com" {
    type master;
    file "master/local_example.zone";
    allow-query {none;};
};

Luego agregue un archivo de zona llamado master/local_example.zoneque contenga lo siguiente:

$TTL 24H
@    SOA LOCALHOST. named-mgr.example.com (1 1d 1h 30d 2h)
     NS  LOCALHOST.

host1.example.com     A   192.168.1.1
host2.example.com     A   192.168.1.2
host3.example.com     A   192.168.1.3
host4.example.com     A   192.168.1.4

Cuando intente resolverlo host1.example.com, obtendrá la respuesta de la response-policyzona y cuando intente resolverlo, mail.example.comlo resolverá utilizando example.comservidores de nombres.

Respuesta2

No es posible utilizar un comodín, así que decidí utilizar un enfoque diferente:

  1. Todos los sitios externos están alojados en el example.comdominio.
  2. Todos los sitios internos están alojados en el int.example.comdominio.

No ha example.comcambiado de ninguna manera y todavía está disponible en Azure DNS (como siempre lo estuvo). El servidor Bind interno ahora aloja el int.example.comdominio y el servidor DHCP también se actualiza para funcionar int.example.comcomo dominio local.

Quiero que mis sitios internos estén disponibles a través de HTTPS, por lo que necesito poder crear certificados usando LetsEncrypt para el int.example.comdominio. LetsEncrypt no puede acceder a mis servicios internos, por lo que tengo que volver a la verificación de DNS.

Agregué la int.example.comzona como zona secundaria example.comen Azure DNS. Esta zona no tendrá ninguna entrada DNS, porque usamos el servidor local para eso. No queremos exponer ninguna información interna a servidores DNS externos. Su único propósito es la verificación de DNS para LetsEncrypt, por lo que AcmeSh debe tener las credenciales adecuadas para crear/eliminar registros TXT. Seguíesta guíapara crear las credenciales adecuadas. Mi configuración utiliza Azure DNS, pero debería funcionar para cualquier DNS que admita subzonas.

información relacionada