Ú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)

También te puede interesar:

• Bind-Named: view internal-in: RFC 1918 response from Internet for…
• Regenerar fichero named.conf en servidores con cPanel
• Cómo ocultar la versión de Bind
• Bind + DNSSEC: has CNAME and other data (invalid)

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

También te puede interesar:

• DNS: configurar bind como Forward Only
• Regenerar fichero named.conf en servidores con cPanel
• Cómo ocultar la versión de Bind
• Bind + DNSSEC: has CNAME and other data (invalid)

$ dig @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57041
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;test.com.            IN    A

 ;; Query time: 214 msec
 ;; SERVER: 10.0.0.115#53(10.0.0.115)
 ;; WHEN: Wed Nov 30 18:00:33 2011
 ;; MSG SIZE  rcvd: 32

Vemos efectivamente que recibimos un SERVFAIL y no hay respuesta del registro A del dominio. El paso siguiente es hacer debug y sacar la traza con +trace para ver todos los saltos y encontrar donde está el problema:

$ dig +trace  @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> +trace @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
.            72650    IN    NS    e.root-servers.net.
.            72650    IN    NS    f.root-servers.net.
.            72650    IN    NS    g.root-servers.net.
.            72650    IN    NS    h.root-servers.net.
.            72650    IN    NS    i.root-servers.net.
.            72650    IN    NS    j.root-servers.net.
.            72650    IN    NS    k.root-servers.net.
.            72650    IN    NS    l.root-servers.net.
.            72650    IN    NS    m.root-servers.net.
.            72650    IN    NS    a.root-servers.net.
.            72650    IN    NS    b.root-servers.net.
.            72650    IN    NS    c.root-servers.net.
.            72650    IN    NS    d.root-servers.net.
;; Received 364 bytes from 10.0.0.115#53(10.0.0.115) in 213 ms

com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 223 ms

test.com.        172800    IN    NS    ns1.servidordns.com.
test.com.        172800    IN    NS    ns2.servidordns.com.
;; Received 117 bytes from 192.48.79.30#53(j.gtld-servers.net) in 341 ms

test.com. 14400 IN A 93.93.108.200
test.com.        86400    IN    NS    ns2.servidordns.com.
test.com.        86400    IN    NS    ns1.servidordns.com.
;; Received 101 bytes from 93.93.108.58#53(ns2.servidordns.com) in 212 ms

Curiosamente, al ejecutar el dig +trace sí que ha llegado al servidor DNS autoritativo y recibido respuesta del registro A. ¿Por qué? Esto es debido a que dig +trace no utiliza la caché del servidor DNS que estamos utilizando. En caso de que esta caché sea incorrecta nos encontraríamos con esta situación.

La solución pasa por reiniciar el servidor DNS que tiene la entrada incorrecta o esperar a que expire el TTL y automáticmaente se actualicen los registros de la zona DNS.

También te puede interesar:

• Activar DEBUG para ASP en IIS7
• Debug de procesos en Solaris con Truss
• Telefónica bloquea el acceso a sus DNS desde redes externas
• Windows Server 2003: no funciona la resolución DNS

1. 80.58.61.250
2. 80.58.61.254
3. 80.58.0.33
4. 80.58.32.97
5. 80.58.32.33
6. 80.58.0.97

El origen de esta restricción es debido a ataques recibidos en sus DNS, flood de paquetes, DDoS, etc. El comunicado oficial es el siguiente:

En el entorno de Telefónica se han producido situaciones de ataque a los DNS que últimamente se han agravado. Los servidores DNS han sido inundado por paquetes o peticiones de resolución, hasta el punto de dejarlos inutilizados. Esto obliga a Telefónica a tomar medidas para salvaguardar la integridad de sus servicios de Internet. Por ello, y para la seguridad del Servicio Internet, se va a proceder a cerrar progresivamente el acceso desde Internet a los diferentes servidores de DNS de Telefónica que a día de hoy están accesibles desde fuera de nuestra red.

Esta medida de seguridad se produce para maximizar la protección de los mismos, dado que Telefonica considera que el servicio DNS propio no debe de estar accesible de forma abierta desde Internet por ser un “servicio de ayuda a la navegación” para los usuarios conectados a nuestra red, y por lo tanto, cada Operador debe disponer de su propio sistema de traducción DNS. Por ello, si está Vd utilizando esta facilidad que ahora mismo está en la Internet pública, proceda a proporcionar un medio de traducción DNS alternativo a los clientes finales que sigan utilizando a día de hoy los DNS de Telefónica. Progresivamente y a partir del 8 de agosto, procederemos a establecer los filtrados de tráfico de entrada a nuestra red con destino a los DNS caches de Telefónica.

Así que ya sabéis. Si usáis estos DNS en entornos de producción deberíais cambiarlos de forma inmediata, utilizar los de otro proveedor, o crear un servidor DNS local para evitar dependencias con otros proveedores.

También te puede interesar:

• ¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?
• Windows Server 2003: no funciona la resolución DNS
• MySQL: resolución de nombres (DNS) y problemas con conexiones remotas
• Hacer que /etc/resolv.conf utilice el DNS secundario o balancee carga

La configuración sería algo así:

nameserver 8.8.8.8
nameserver 8.8.4.4

En este caso si 8.8.8.8 falla la resolución se realizará a través de 8.8.4.4. El problema es que por defecto el valor de tiempo de espera (TIMEOUT) asignado es bastante alto, creo recordar que 5 segundos, por lo que tardará un tiempo en detectar que tiene que utilizar el segundo DNS y todo irá muy lento. Para solucionarlo, tenemos que usar la directiva “options” y modificar el timeout, podemos poner 1 segundo:

nameserver 8.8.8.8
nameserver 8.8.4.4
options timeout:1

Otra opción también interesante es “rotate”, que permite distribuir la carga entre todos los servidores listados y evitar que todas las peticiones vayan siempre al primero:

nameserver 8.8.8.8
nameserver 8.8.4.4
options timeout:1 rotate attempts:1

Configurando estas opciones aseguramos que en caso del fallo del servidor DNS principal el rendimiento de la máquina  no se degrade. Podéis observar más directivas en la página man correspondiente:

$ man resolv.conf

También te puede interesar:

• Cómo cambiar los servidores DNS desde línea de comandos
• ¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?
• Telefónica bloquea el acceso a sus DNS desde redes externas
• Windows Server 2003: no funciona la resolución DNS

Resolución inversa (reverse DNS) en Unix/Linux

Para verificar la resolución inversa en Linux utilizaremos el comando “host”:

# host ip

Ejemplos:

Google:

# host 66.102.9.105
105.9.102.66.in-addr.arpa domain name pointer lm-in-f105.1e100.net.

Telefónica:

# host 80.58.0.33
33.0.58.80.in-addr.arpa domain name pointer 33.Red-80-58-0.staticIP.rima-tde.net.

Resolución inversa (reverse DNS) en Windows

Para windows utilizaremos el comando nslookup, que realmente también podríamos utilizar en Unix. El proceso es el siguiente:

Google:

# nslookup 66.102.9.105
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
105.9.102.66.in-addr.arpa       name = lm-in-f105.1e100.net.

Telefónica:

 nslookup 80.58.0.33
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
33.0.58.80.in-addr.arpa name = 33.Red-80-58-0.staticIP.rima-tde.net.

En NixCraft encontraréis unas cuantas formas más de hacerlo.

También te puede interesar:

• Cómo vaciar ficheros en Linux
• eBook gratuito: The Linux Command Line
• Crea imagenes de arranque Windows o Linux en tu USB
• Apagar o reiniciar máquina Windows remotamente desde Linux

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.

También te puede interesar:

• Regenerar fichero named.conf en servidores con cPanel
• Bind DNS: Zone transfer deferred due to quota
• Cómo ocultar la versión de Bind
• DNS: configurar bind como Forward Only

Si queremos modificar los servidores DNS a utilizar en nuestra máquina (Unix, Linux), simplemente hay que listarlos dentro del fichero /etc/resolv.conf del siguiente modo:

$ vi /etc/resolv.conf
nameserver 80.58.0.33
nameserver 80.58.32.97

No es necesario reiniciar la red para que los cambios surtan efecto. Simplemente haced ping a un dominio para ver si el funcionamiento de resolución de nombres es correcto:

$ ping google.com
PING google.com (74.125.53.100) 56(84) bytes of data.
64 bytes from pw-in-f100.1e100.net (74.125.53.100): icmp_seq=1 ttl=46 time=541 ms
64 bytes from pw-in-f100.1e100.net (74.125.53.100): icmp_seq=2 ttl=46 time=263 ms

Una buena base de datos con todos los DNS disponibles de los proveedores de Internet en España es la de ADSL ayuda.

También te puede interesar:

• Hacer que /etc/resolv.conf utilice el DNS secundario o balancee carga
• ¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?
• Telefónica bloquea el acceso a sus DNS desde redes externas
• Windows Server 2003: no funciona la resolución DNS

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.

También te puede interesar:

• Regenerar fichero named.conf en servidores con cPanel
• Bind + DNSSEC: has CNAME and other data (invalid)
• Cómo ocultar la versión de Bind
• DNS: configurar bind como Forward Only