Source: https://www.josedomingo.org/pledin/2017/12/vistas-views-en-el-servidor-dns-bind9/
Timestamp: 2019-04-23 23:59:17+00:00

Document:
Vistas (views) en el servidor DNS Bind9 - PLEDIN 3.0
Vistas (views) en el servidor DNS Bind9
En alguna circunstancia nos puede interesar que un mismo nombre que resuelve nuestro DNS devuelva direcciones IP distintas según en que red este conectada el cliente que realiza la consulta. Por ejemplo:
Si tenemos un servidor DNS que da servicio a internet y a intranet. Si se realiza la consulta desde internet, por ejemplo al nombre www.example.org debe devolver a la IP pública, sin embargo si se hace la misma consulta desde la intranet la resolución deberá ser a una IP privada.
Otro ejemplo es en la resolución de nombres de instancias de OpenStack. En este caso una instancia tiene asignada una IP privada en el rango en el que hemos configurado la red interna, además puede tener asignada una IP flotante en el rango de la configuración que hayamos hecho de la red externa. En este caso sería deseable que cuando hago una consulta desde el exterior me resuelva con la IP flotante, y cuando haga una consulta desde otra instancia conecta da a la red interna me devuelva la dirección fija asignada a la instancia.
Vamos a ver un ejemplo del uso de vistas (views) en bind9 para configurar dos zonas diferenciadas para el mismo nombre de dominio y que se utilicen según desde donde se solicite la resolución.
Escenario de nuestro ejemplo
Hemos creado una instancia en OpenStack con el siguiente esquema de red:
La red interna tiene como direccionamiento 10.0.0.0/24 y la red externa 172.22.0.0/16. Vamos a configurar bind9 para que cuando se consulte el nombre del servidor desde la red externa devuelva la ip flotante (172.22.0.129) y cuando la consulta se realice desde la red interna se devuelva la ip fija (10.0.0.13).
Uso de vistas en bind9
Al utilizar “views” en bind9 vamos a tener zonas diferencias según el origen de la consulta. Por lo tanto vamos a crear dos “acl” par filtrar las redes desde las que se hacen las consultas y posteriormente dentro de cada vista definiremos las zonas con autoridad del servidor. De esta manera el fichero /etc/bind/named.conf.local quedaría de la siguiente manera:
acl interna { 10.0.0.0/24; localhost; };
acl externa { 172.22.0.0/16; };
view todas {
match-clients { interna; externa;};
view interna {
zone "example.org"
file "db.interna.example.org";
zone "0.0.10.in-addr.arpa"
view externa {
match-clients { externa; };
file "db.externa.example.org";
zone "22.172.in-addr.arpa"
file "db.22.172";
Hemos creado las dos “acl” para diferenciar las redes por las que vamos a consultar:
La zona que se va a utilizar será la definida en la vista donde hayamos definidos las IP desde las que se hace las consultas:
Otro detalle que tenemos que tener en cuanta al utilizar vistas, es que todas las zonas definidas deben estar dentro de una zona, por lo tanto las zonas de resolución inversa definidas en el RFC1918 y las zonas por defecto, la hemos incluido en cada una de las vistas:
Y no se nos puede olvidar eliminar las zonas por defecto del fichero named.conf:
La configuración de la zona directa para la vista interna quedaría el fichero /var/cache/bind/db.interna.example.org:
@   IN  SOA instancia1.example.org. root.example.org. (
@   IN  NS  instancia1.example.org.
instancia1.example.org. IN  A   10.0.0.13
De forma similar la vista externa de la zona de resolución directa en el fichero /var/cache/bind/db.externa.example.org:
instancia1.example.org. IN  A   172.22.200.129
Y las zonas de resolución inversa para las dos vistas serían:
En le fichero /var/cache/bind/db.0.0.10:
13.0.0.10.in-addr.arpa. IN  PTR instancia1.example.org.
Y en el fichero /var/cache/bind/db.22.172:
129.200.22.172.in-addr.arpa.    IN  PTR instancia1.example.org.
Si hacemos una consulta a nuestro servidor desde la red 10.0.0.0/24:
dig @10.0.0.13 instancia1.example.org
; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.13 instancia1.example.org
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30042
;instancia1.example.org.        IN  A
instancia1.example.org. 86400   IN  A   10.0.0.13
;; SERVER: 10.0.0.13#53(10.0.0.13)
;; WHEN: Thu Dec 28 12:45:48 UTC 2017
Si por el contrario hacemos la consulta desde la red 172.22.0.0/16:
dig @172.22.200.129 instancia1.example.org
; <<>> DiG 9.10.3-P4-Debian <<>> @172.22.200.129 instancia1.example.org
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42980
instancia1.example.org. 86400   IN  A   172.22.200.129
;; SERVER: 172.22.200.129#53(172.22.200.129)
;; WHEN: Thu Dec 28 12:44:52 UTC 2017
Y las consultas inversa de la misma manera, desde la red interna:
dig @10.0.0.13 -x 10.0.0.13
; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.13 -x 10.0.0.13
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19579
;13.0.0.10.in-addr.arpa.        IN  PTR
13.0.0.10.in-addr.arpa. 86400   IN  PTR instancia1.example.org.
;; WHEN: Thu Dec 28 12:48:21 UTC 2017
Y desde la red externa:
dig @172.22.200.129 -x 172.22.200.129
; <<>> DiG 9.10.3-P4-Debian <<>> @172.22.200.129 -x 172.22.200.129
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52169
;129.200.22.172.in-addr.arpa.   IN  PTR
129.200.22.172.in-addr.arpa. 86400 IN   PTR instancia1.example.org.
;; WHEN: Thu Dec 28 12:46:55 UTC 2017
Si ofrecemos servicios a distintas redes (distinto direccionamiento), usar las vistas en el servidor DN bind9 nos puede ayudar a utilizar un mismo nombre para cada servicio independientemente desde donde se haga la consulta. La resolución de cada nombre dependerá del origen de la consulta.
Etiquetas: bind9, dns
Actualizado: December 28, 2017

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución