Si queremos que nuestro servidor DNS actúe a modo de proxy DNS y reenviar todas las peticiones que reciba a otros servidores DNS debemos configurarlo como “Forward Only“. Esto tiene todos los beneficios que puede darte un proxy y otros como por ejemplo, si tenemos Bind configurado con vistas, especificar el forwarding para la vista externa pero mantener las consultas a las zonas locales en el propio DNS.
Únicamente hay que prestar atención a dos directivas en la sección de opciones (options), marcadas en negrita:
options {
listen-on port 53 { 127.0.0.1; 10.0.0.100; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
allow-query { redes_privadas; }; forward only;
forwarders { 8.8.8.8; };
};
La directiva “forward” permite los valores “only” y “first”. Si especificamos “only” todas las consultas serán reenviadas a los nameserver especificados después. Si ponemos “first” se realizará un primer intento contra los NS forward, si estos no responden la consulta se intentará resolver en local.
Después, en forwarders podemos especificar los servidores DNS contra los que vamos a enrutar las peticiones DNS. En este caso he configurado el de google, 8.8.8.8.
Tras reiniciar named, podemos verificar (con un tcpdump por ejemplo) que las consultas efectivamente se están enrutando a esos DNS:
# dig @localhost www.rm-rf.es
...
...
Y efectivamente vemos el tráfico en el tcpdump contra el NS de google:
# tcpdump -n -s 1500 -i eth0 udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
23:19:21.230065 IP 192.168.1.101.22581 > 8.8.8.8.domain: 31993+ [1au] A? www.rm-rf.es. (41)
23:19:21.371260 IP 8.8.8.8.domain > 192.168.1.101.22581: 31993 3/0/1 CNAME rm-rf.es., A 93.93.112.55, RRSIG (239)
23:19:38.683764 IP 192.168.1.128.57988 > 192.168.1.1.domain: 64751+ A? rm-rf.es. (26)
23:19:38.722404 IP 192.168.1.1.domain > 192.168.1.128.57988: 64751 1/0/0 A 93.93.112.55 (42)
En un servidor DNS montado con Bind, podéis encontrar un error como este en el log:
09-Jan-2012 08:23:44.055 client 10.0.0.50#59382: view internal-in:
RFC 1918 response from Internet for 50.0.0.10.in-addr.arpa
El error es totalmente descriptivo, sólo hay que revisar la RFC 1918 y leer dos veces el error para darnos cuenta del fallo. En este caso estamos tratando de buscar en Internet una IP que pertenece a un rango privado. Podemos ver que además nos responde con la vista privada del named.
Rangos privados:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Lo más sencillo y rápido es declarar la zona en la configuración de nuestro Bind, no es necesario ni crear el fichero de la zona:
zone "10.in-addr.arpa" {
type master;
file "named.empty";
};
Es posible que en lugar de así tengáis que ponerlo tal que:
zone "10.in-addr.arpa" {
type master;
file "empty";
};
El link al RFC: RFC 1918 – Address Allocation for Private Internets
Pese a que no es habitual, puede que en algún momento necesitéis regenerar el fichero de configuración de named (named.conf). En mi caso no era por borrado accidental del fichero sino porque necesitaba actualizarlo tras una migración en masa de zonas DNS (necesitaba que se incluyeran en el named.conf).
Bien, cPanel pone a nuestra disposición un script que regenera el fichero named.conf a partir de las zonas DNS alojadas en /var/named/. El script a ejecutar es “/scripts/rebuilddnsconfig“.
# /scripts/rebuilddnsconfig
Una vez ejecutado debería haberse regenerado correctamente. Es posible que haya alguna incongruencia, en ese caso os mostraría los errores por pantalla. Ejemplo:
Named could not be restarted, any obvious config errors should show up below this line.
WARNING: /etc/named.conf appears to contain errors which could not be corrected automatically!
/etc/named.conf:6552: zone 'xxxx.com': already exists previous definition: /etc/named.conf:4980
/etc/named.conf:6558: zone 'xxxx.biz': already exists previous definition: /etc/named.conf:2590
Please correct these errors manually and rerun /scripts/fixrndc
En ese caso tenemos llamadas a unas zonas duplicadas. Simplemente eliminamos la llamada duplicada y ejecutaríamos “/scripts/fixrndc” para levantar de nuevo named una vez solucionados los errores:
# /scripts/fixrndc
Hoy realizando el firmado de unas zonas en un servidor DNS montado con Bind + Dnssec recibía el siguiente error en la zona de un dominio al firmarla con zonesigner:
xxxx.xx has CNAME and other data (invalid)
El problema residía en que el dominio tenía declarado un registro CNAME Wildcard y después otro con un subdominio hacia el mismo destino:
midominio.com. IN CNAME test.com.
* IN CNAME test.com.
Para solucionarlo eliminamos el registro que genera la duplicación y quedaría solucionado:
* IN CNAME test.com.
El fallo también puede surgir si hay un registro CNAME y alguno de otro tipo dentro de la misma zona:
www IN A 192.168.0.11
www IN CNAME test.com.
Para solucionarlo tendríamos que eliminar uno de los dos.
Este error podéis encontrarlo en los logs de un servidor DNS esclavo con BIND, y es provocado cuando el servidor DNS maestro está transfiriendo una gran cantidad de zonas DNS al esclavo de forma concurrente.
Ejemplo:
13-Jul-2009 05:24:38.360 xfer-in: info: zone xxx1.net/IN: zone transfer deferred due to quota
13-Jul-2009 05:24:38.360 xfer-in: info: zone xxx2.com/IN: zone transfer deferred due to quota
13-Jul-2009 05:24:38.361 xfer-in: info: zone xxx3.com/IN: zone transfer deferred due to quota
13-Jul-2009 05:24:38.361 xfer-in: info: zone xxx4.com/IN: zone transfer deferred due to quota
13-Jul-2009 05:24:38.361 xfer-in: info: zone xxx5.com/IN: zone transfer deferred due to quota
Por defecto, bind permite una concurrencia de 10 transferencias de zona. Este número puede ser insuficiente en servidores DNS con gran número de zonas, y que además añada nuevas de forma constante y concurrente.
Para solucionarlo debemos añadir en el fichero de configuración named.conf del servidor esclavo la directiva transfers-in con el nº de transferencias concurrentes que queramos. Debe ir dentro de la sección de opciones globales:
options {
transfers-in 50;
};
Y en el servidor maestro configuramos el nº de transferencias concurrentes que permitimos (de salida, mientras que en el esclavo es de entrada):
options {
transfers-out 50;
};
Recargamos la configuración de named y el nuevo valor comenzará a surtir efecto.
BIND (Berkeley Internet Name Domain, anteriormente : Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en los cuales es un standard de facto.
Independientemente de que esta no sea la panacea para evitar un ataque a un servidor DNS, siempre es recomendable ocultar toda la información que sea posible sobre versiones de servicios instalados en una máquina, y por supuesto siempre es recomendable mantener el servicio a la última versión estable.
Para ocultar la versión de Bind, debemos editar el fichero de configuración named.conf:
$ vi /etc/named.conf
Añadiremos la siguiente línea (con el texto que os apetezca) dentro de la sección de opciones:
options {
version "Seguramente estas bromeando";
}
Reiniciamos named y ya debería aparecer enmascarada la versión de Bind:
service named restart
o
/etc/init.d/named restart
Podemos testearlo así:
$ dig @servidordns version.bind txt chaos
; <<>> DiG 9.4.2 <<>> @xxxxx version.bind txt chaos
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33774
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "Seguramente estas bromeando"
;; Query time: 247 msec
;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx)
;; WHEN: Mon Sep 1 22:55:41 2008
;; MSG SIZE rcvd: 70
Comentarios recientes