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.
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.
Parece ser que es un problema bastante común pero que a mi personalmente me ha dado algún que otro dolor de cabeza. El fallo consiste en que en Windows 2003 Server no funciona la resolución de nombres DNS, por lo que no podemos navegar de forma correcta, realizar actualizaciones, etc.
Pero el fallo realmente está localizado en la instalaciónes realizadas a través de una imagen del sistema, clon, etc. En mi situación el problema se reproducía con una imagen de Altiris HP Deployment Server. Los sintomas son los siguientes:
- Hay conectividad a redes públicas (ping 8.8.8.8) pero no resolución DNS (ping google.com).
- La resolución de nombres a través de nslookup funciona correctamente.
- Tampoco funciona la resolución DNS añadiendo los dominios al fichero hosts (en \Windows\system32\drivers\etc\).
El problema tiene su origen en que al restaurar estas imágenes se borra una entrada del registro de Windows, la culpable de estos errores. El valor del registro se encuentra en:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
La solución pasa por revisar que exista la entrada “Domain” del tipo REG_SZ:
Si no existe, creadla. En cuanto la creéis la resolución DNS debería volver a funcionar de forma instantanea, sin necesidad de reinicio. Hay casos en los que también hay que recrear la entrada “NV Domain” o “NV Hostname”, cuyo valor es el hostname de la máquina. En mi caso únicamente fue necesario regenerar la variable “Domain” para que todo funcionara bien.
Durante un rato, hoy me ha traído de cabeza un problema con un servidor MySQL en el que se estaban encolando todas las conexiones, las cuales no llegaban a conectar y se bloqueaban del siguiente modo:
| 64 | unauthenticated user | 10.0.3.17:37723 | | Connect | | login | |
| 65 | unauthenticated user | 10.0.3.6:45973 | | Connect | | login | |
| 66 | unauthenticated user | 10.0.3.6:45974 | | Connect | | login | |
| 67 | unauthenticated user | 10.0.3.6:45975 | | Connect | | login | |
| 68 | unauthenticated user | 10.0.3.6:45976 | | Connect | | login | |
| 69 | unauthenticated user | 10.0.3.6:45977 | | Connect | | login | |
| 70 | unauthenticated user | 10.0.3.6:45978 | | Connect | | login | |
| 71 | unauthenticated user | 10.0.3.6:45979 | | Connect | | login | |
| 72 | unauthenticated user | 10.0.3.6:45980 | | Connect | | login | |
| 73 | unauthenticated user | 10.0.3.6:45981 | | Connect | | login | |
En el momento que he verificado que el problema surgía únicamente con las conexiones remotas he comenzado a revisar las distintas posibilidades, entre las que se encontraba por ejemplo revisar que los usuarios MySQL estuvieran correctamente configurados, que no hubiera problemas en las bases de datos, etc. Pero realmente el problema surgía mucho antes, en el momento en el que se establecía la conexión, antes de siquiera pedir credenciales.
En este caso el problema radicaba en que los servidores DNS configurados para la máquina (en /etc/resolv.conf) no funcionaban correctamente e impedían a MySQL resolver los hosts remotos que intentaban conectar. MySQL siempre que recibe una conexión remota vía IP intenta revisar a que nombre resuelve para posteriormente hacer el paso contrario y verificar/comparar que el host también resuelve a dicha IP original. El servidor no pasaba de aquí y generaba el cuello de botella.
Si queremos evitar que esto suceda una de dos, o nos aseguramos que los servidores DNS resuelven rápida y correctamente o deshabilitamos la resolución de nombres con –skip-name-resolve, en este caso únicamente podremos usar IPs y no hosts en la tabla de privilegios.
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
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
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.
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.
Comentarios recientes