Anulación de algunas entradas DNS en BIND para redes internas

Tengo una red interna con un servidor DNS que ejecuta BIND, conectado a Internet a través de una única puerta de enlace. Mi dominio "example.com" es administrado por un proveedor de DNS externo. Algunas de las entradas en ese dominio, como "host1.example.com" y "host2.example.com", así como la entrada de nivel superior "example.com", apuntan a la dirección IP pública de la puerta de enlace.

Me gustaría que los hosts ubicados en la red interna resuelvan "host1.example.com", "host2.example.com" y "example.com" a direcciones IP internas en lugar de la de la puerta de enlace. Otros hosts como "otherhost.example.com" aún deben ser resueltos por el proveedor de DNS externo.

He logrado hacer eso para las entradas host1 y host2, definiendo dos zonas de entrada única en BIND para "host1.example.com" y "host2.example.com". Sin embargo, si agrego una zona para "example.com", mi servidor DNS local resuelve todas las consultas para ese dominio y, por ejemplo, al consultar "otherhost.example.com" se produce un error.

¿Es posible configurar BIND para anular solo algunas entradas de un dominio y resolver el resto de forma recursiva?

El mejor método es a través de la zona de política de respuesta en Bind 9.8.1 o posterior. Le permite anular registros únicos en zonas arbitrarias (y no es necesario crear un subdominio completo para eso, solo el registro único que desea cambiar), le permite anular CNAME, etc. Otras soluciones como Unbound no pueden anular CNAME .

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html

EDITAR: Hagamos esto correctamente entonces. Documentaré lo que he hecho en base al tutorial vinculado anteriormente.

Mi sistema operativo es Raspbian 4.4 para Raspberry Pi, pero la técnica debería funcionar sin cambios en Debian y Ubuntu, o con cambios mínimos en otras plataformas.

Vaya a donde se guardan sus archivos de configuración de Bind en su sistema, aquí está /etc/bind. Cree allí un archivo llamado db.rpzcon los siguientes contenidos:

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

¿Qué hace?

• anula la dirección IP www.some-website.comcon la dirección falsa 127.0.0.1, enviando efectivamente todo el tráfico de ese sitio a la dirección de bucle invertido
• envía tráfico www.other-website.coma otro sitio llamadofake-hostname.com

Cualquier cosa que pueda ir en un archivo de zona Bind puede usar aquí.

Para activar estos cambios, hay algunos pasos más:

Edite named.conf.localy agregue esta sección:

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

El tutorial vinculado anteriormente le dice que agregue más cosas, zone "rpz" { }pero eso no es necesario en configuraciones simples: lo que he mostrado aquí es lo mínimo para que funcione en su resolutor local.

Edite named.conf.optionsy en algún lugar de la options { }sección agregue la response-policyopción:

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Ahora reinicie Bind:

service bind9 restart

Eso es. El servidor de nombres debería comenzar a anular esos registros ahora.

Si necesita hacer cambios, simplemente edite db.rpz, luego reinicie Bind nuevamente.

Bonificación: si desea registrar consultas DNS en syslog, para que pueda vigilar los procedimientos, editar named.conf.localy asegurarse de que haya una loggingsección que incluya estas declaraciones:

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Reinicie Bind nuevamente y listo.

Pruébelo en la máquina que ejecuta Bind:

dig @127.0.0.1 www.other-website.com. any

Si ejecuta dig en una máquina diferente, simplemente use @ the-ip-address-of-Bind-server en lugar de @ 127.0.0.1

Utilicé esta técnica con gran éxito para anular el CNAME de un sitio web en el que estaba trabajando, enviándolo a un nuevo equilibrador de carga de AWS que estaba probando. Se utilizó una Raspberry Pi para ejecutar Bind, y el RPi también se configuró para funcionar como un enrutador WiFi, por lo que al conectar dispositivos al SSID que se ejecuta en el RPi obtendría las anulaciones de DNS que necesitaba para las pruebas.

El consolidar servidor DNS recursivo tiene la capacidad de anular los registros de recursos individuales.

Mira las local-zoney local-dataconfiguración de ajustes en el manual de , por ejemplo:

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

La transparentconfiguración en local-zonele dice que haga búsquedas recursivas normales para cualquier nombre que no se proporcione local-data.

Es posible que desee buscar en "dnsmasq", que le permite hacer algunas cosas bastante inteligentes con una resolución de ajuste.

Lo que está buscando es DNS dividido, que Webopedia define como:

En una infraestructura de DNS dividida, crea dos zonas para el mismo dominio, una para ser utilizada por la red interna y la otra para la red externa. El DNS dividido dirige los hosts internos a un servidor de nombres de dominio interno para la resolución de nombres y los hosts externos se dirigen a un servidor de nombres de dominio externo para la resolución de nombres.

Esencialmente, necesitará hacer una copia de su archivo de zona externa y apuntalarlo en su servidor DNS interno, luego cambiar o agregar los registros necesarios específicamente para su red interna. Esta es una configuración bastante común, aunque puede ser una molestia mantener los registros "externos" sincronizados entre los dos servidores DNS. Si crea o cambia un registro en el servidor público, también deberá crearlo o cambiarlo en el servidor privado.

Esto se puede implementar independientemente de la implementación del servidor DNS que use. En la mayoría de las configuraciones, tendrá un servidor DNS que sirve a la red externa y otro diferente que sirve a la red interna. Con BIND, como posiblemente otras implementaciones, puede tener ambas versiones de la zona en el mismo servidor mediante el uso de la instrucción "allow-query" dentro de la sección de zona del archivo named.conf.

Otra posibilidad en BIND (y nunca lo he intentado) sería establecer su dominio example.com en el servidor DNS interno con solo los registros que usa internamente. Luego, establezca una declaración de "reenvío" con el "primer" argumento (junto con "reenviadores"). En teoría, esto iría a pedir una respuesta al servidor DNS externo (como se establece en "reenviadores", que no tendría sus registros internos y devolvería una respuesta de falla. Luego, el servidor interno se buscaría una respuesta. Seguro si eso funcionaría, pero es un pensamiento.

En BIND llego a estos resultados definiendo una zona usando el nombre de host deseado. El enfoque está bien si solo desea anular algunos hosts.

Mi declaración de zona se ve así:

zone "override.example.com" {
        type master;
        notify no;
        file "zone-config/override.example.com";
};

La definición de mi zona se ve así:

$TTL 4H
@       IN      SOA     ns.override.example.com.    root.override.example.com. (
                        2009072215      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        604800          ; Expire
                        3600    )       ; Minimum
;
                NS      ns
        IN      NS      ns.override.example.com.
        IN      A       192.168.1.100
ns      IN      A       192.168.1.100

Entonces, si consulto example.com en el DNS de la intranet y el ISP DNS obtengo la misma IP pero si consulto override.example.com obtengo resultados diferentes si se puede acceder al DNS de la intranet (primario).

Ya estás en el camino correcto.

En sus servidores DNS internos, deberá definir una zona para cada host de excepción inmediatamente debajo de "example.com". Para minimizar estas excepciones, es una práctica común nombrar todas las máquinas internas "hosta.internal.example.com", con el servidor DNS enviando la mayoría de las consultas a servidores DNS externos, pero autorizadas para la zona "internal.example.com". (Una vez que pasa una pequeña operación, generalmente hay un par de servidores DNS a los que se dirigen los clientes y un DNS autorizado por separado al que se dirigen esos servidores para "internal.example.com").

Por lo general, solo cuando un host debe ser accesible tanto externa como internamente, se crean las excepciones que usted describe. Incluso entonces, puede utilizar "host1.example.com" desde afuera y "host1.external.example.com" desde adentro. Los hosts internos se configuran para buscar nombres dentro de "internal.example.com". Hay situaciones en las que lo que ya está haciendo es apropiado, como si el certificado de un servidor identifica al servidor como "host1.example.com", en cuyo caso desea que ese sea el nombre al que se conectan los clientes.

Usar dnsmasq lo hace realmente fácil. http://www.thekelleys.org.uk/dnsmasq/doc.html Actúa como el servidor DNS pero obtiene respuestas del servidor DNS local. Lo bueno es que puede anular registros de dominio único sin alterar los archivos de zona

De hecho, hay otra forma, aunque sea ligeramente diferente, de hacerlo. Tengo la misma situación, tengo un dominio que se usa externa e internamente, y tengo hosts externos estáticos y dinámicos. Los únicos realmente dolorosos son los dinámicos externos. La solución posiblemente no sea la más elegante, pero se puede implementar con un script pequeño. Principalmente estoy haciendo mi propio script DNS dinámico con la API de mi proveedor de DNS dinámico, ejecuto este script por cron, cada 5 minutos:

1) obtener mi IP externa. ha cambiado? Sin salida.

2) IP cambiada, API de llamada de dyndns-provider, con la nueva dirección IP,

3) sed el db.mydomain.com con la IP externa

4) reiniciar el enlace.

Funciona de manera muy confiable para mi red doméstica