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
También te puede interesar:
Analizando un problema de resolución DNS esta tarde he detectado algo que me ha parecido curioso. El dominio en cuestión no resolvía utilizando un determinado servidor DNS. Voy a enseñaros el ejemplo con un servidor DNS ficticio “10.0.0.115″ y un nombre de dominio “test.com”:
$ 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:
En las últimas semanas se estaba empezando a detectar fallos cuando se utilizaban los DNS de Telefónica en redes externas. Esto solía pasar de forma esporádica pero al parecer el bloqueo se va a hacer oficial en poco tiempo. Las IPs de servidores DNS de telefónica son:
- 80.58.61.250
- 80.58.61.254
- 80.58.0.33
- 80.58.32.97
- 80.58.32.33
- 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:
En el fichero /etc/resolv.conf se especifican los servidores DNS que utiliza el sistema para la resolución de nombres. Normalmente se ponen más de uno para que en caso de que el principal falle el siguiente tome el control y se evite la ralentización del sistema, no poder entrar por SSH, etc.
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:
Comprobar la resolución de DNS inversa significa verificar el hostname al que resuelve una IP determinada (como sabréis normalmente se busca lo contrario).
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:
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.
También te puede interesar:
Cualquier máquina conectada a Internet debe tener configurados unos servidores DNS que servirán para la resolución de nombres de todas aquellas aplicaciones que se conecten a Internet. Básicamente (no voy a profundizar en esto) traducirán los nombres de dominio a IPs.
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:
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.
También te puede interesar:
Comentarios recientes