Resolución inversa DNS

 
 

Este es el quinto de los artículos dedicados al DNS publicados en ZeppelinuX. Tras explicar en artículos anteriores el funcionamiento de la resolución directa, en este artículo veremos en que consiste la resolución inversa, es decir, preguntaremos por una dirección IP en lugar de preguntar por un nombre de dominio. Si te interesa ver el artículo anterior, Clientes DNS, Proceso de resolución, Caché, TTL y Recursividad, solo tienes que pinchar aquí.

Índice General

1. Resolución inversa
• Mapeo de direcciones IP y el dominio arpa.
• Zonas de resolución inversa.
• Proceso de resolución.
• Delegación y resolución inversa.

 

1. Resolución inversa (Volver al índice General)
   La resolución inversa consiste en obtener información de un nombre de dominio preguntando por la dirección IP en vez de preguntar por el nombre de domino como hemos hecho en artículos anteriores. Por ejemplo, preguntar cual o cuales son los nombres de dominio asociados a la dirección IP 8.8.8.8.

   En el siguiente ejemplo, por medio del cliente DNS nslookup preguntaremos por la dirección IP 8.8.8.8.

   $ nslookup 8.8.8.8 Servidor: 250.red-80-58-61.staticip.rima-tde.net Address: 80.58.61.250   Nombre: google-public-dns-a.google.com Address: 8.8.8.8

   $ nslookup 8.8.8.8 Servidor: 250.red-80-58-61.staticip.rima-tde.net Address: 80.58.61.250 Nombre: google-public-dns-a.google.com Address: 8.8.8.8

   Normalmente la resolución inversa se utiliza, por ejemplo, para resolver problemas de red, detectar spam en los servidores de correo, seguir la traza de un ataque, conocer que nombres aloja un servidor de hosting, etc.

   En el siguiente ejemplo, ejecutamos el comando tracert -d www.google.es y se muestran las direcciones IP de los routers por los que van pasando los paquetes de datos hasta llegar al equipo www.google.es.

   C:\Users\mortadelo>tracert -d www.google.es   Traza a la dirección www.google.es [216.58.211.35] sobre un máximo de 30 saltos:   1 319 ms 7 ms 9 ms 192.168.1.1 2 64 ms 157 ms 69 ms 80.58.67.124 3 * * * Tiempo de espera agotado para esta solicitud. 4 * * * Tiempo de espera agotado para esta solicitud. 5 * * * Tiempo de espera agotado para esta solicitud. 6 68 ms 72 ms 163 ms 176.52.253.97 7 136 ms 76 ms 173 ms 72.14.211.154 8 * * * Tiempo de espera agotado para esta solicitud. 9 79 ms 117 ms 194 ms 108.170.233.246 10 100 ms 118 ms 67 ms 108.170.234.231 11 71 ms 71 ms 82 ms 216.58.211.35   Traza completa.

   C:\Users\mortadelo>tracert -d www.google.es Traza a la dirección www.google.es [216.58.211.35] sobre un máximo de 30 saltos: 1 319 ms 7 ms 9 ms 192.168.1.1 2 64 ms 157 ms 69 ms 80.58.67.124 3 * * * Tiempo de espera agotado para esta solicitud. 4 * * * Tiempo de espera agotado para esta solicitud. 5 * * * Tiempo de espera agotado para esta solicitud. 6 68 ms 72 ms 163 ms 176.52.253.97 7 136 ms 76 ms 173 ms 72.14.211.154 8 * * * Tiempo de espera agotado para esta solicitud. 9 79 ms 117 ms 194 ms 108.170.233.246 10 100 ms 118 ms 67 ms 108.170.234.231 11 71 ms 71 ms 82 ms 216.58.211.35 Traza completa.

   El siguiente ejemplo es similar al anterior pero sin la opción -d, en este caso, en lugar de mostrar las direcciones IP de los routers, se muestran nombres de dominio ya que el programa tracert está haciendo preguntas DNS inversas para obtener los nombres de dominio asociados a las IPs de los routers.

   C:\Users\karfer>tracert www.google.es   Traza a la dirección www.google.es [172.217.16.227] sobre un máximo de 30 saltos:   1 14 ms 89 ms 46 ms rutix1 [192.168.1.1] 2 56 ms 59 ms 151 ms 124.red-80-58-67.staticip.rima-tde.net [80.58.67.124] 3 * * * Tiempo de espera agotado para esta solicitud. 4 * * * Tiempo de espera agotado para esta solicitud. 5 * * * Tiempo de espera agotado para esta solicitud. 6 * 76 ms 71 ms 176.52.253.97 7 75 ms 69 ms 107 ms 72.14.211.154 8 * * * Tiempo de espera agotado para esta solicitud. 9 168 ms 70 ms 65 ms 172.253.50.10 10 69 ms 67 ms 73 ms mad08s04-in-f3.1e100.net [172.217.16.227]   Traza completa.

   C:\Users\karfer>tracert www.google.es Traza a la dirección www.google.es [172.217.16.227] sobre un máximo de 30 saltos: 1 14 ms 89 ms 46 ms rutix1 [192.168.1.1] 2 56 ms 59 ms 151 ms 124.red-80-58-67.staticip.rima-tde.net [80.58.67.124] 3 * * * Tiempo de espera agotado para esta solicitud. 4 * * * Tiempo de espera agotado para esta solicitud. 5 * * * Tiempo de espera agotado para esta solicitud. 6 * 76 ms 71 ms 176.52.253.97 7 75 ms 69 ms 107 ms 72.14.211.154 8 * * * Tiempo de espera agotado para esta solicitud. 9 168 ms 70 ms 65 ms 172.253.50.10 10 69 ms 67 ms 73 ms mad08s04-in-f3.1e100.net [172.217.16.227] Traza completa.

 
• Mapeo de direcciones IP y el dominio arpa (Volver al índice General)
  El funcionamiento de la resolución de direcciones IP es igual al de la resolución de nombrres de dominio. Las direcciones IP se tratan como nombres que cuelgan del dominio «in-addr.arpa» para las direcciones IPv4, y del dominio «ip6.arpa» para las direcciones IPv6.
  
  Por ejemplo, el dominio «www.zeppelinux.es» lo leemos y escribimos de izquierda a derecha, pero su estructura jerárquica es de derecha a izquierda, el dominio más alto de la jerarquía es el dominio raíz «.», después «es», después «zeppelinux» y por último «www».

  Cuando usamos una dirección IP, por ejemplo «192.168.1.21», para realizar una pregunta DNS inversa, en realidad estamos preguntando por el nombre de dominio «21.1.168.192.in-addr.arpa». La estructura jerárquica de la dirección IP, tratada como nombre de dominio, es de derecha a izquierda, comenzando por el dominio «in-addr.arpa».

  .arpa (Address and Routing Parameter Area) es un dominio de nivel superior genérico utilizado sólo para la infraestructura de Internet. Los subdominios de .arpa o dominios de segundo nivel «in-addr.arpa» e «ip6.arpa» son usados por los servidores DNS inversos para la obtención de direcciones IPv4 e IPv6 respectivamente.

  Cuando mapeamos una dirección IP estamos asociando la dirección IP al nombre en el dominio .arpa. Por ejemplo la dirección «192.168.1.21» es mapeada al nombre «21.1.168.192.in-addr.arpa».

 

• Zonas de resolución inversa (Volver al índice General)
  Los servidores DNS almacenan zonas de resolución inversa con registros de recursos (RR) que asocien nombres de dominio con direcciones IP. Las zonas de resolución inversa pueden ser maestras o primarias y esclavas o secundarias.

  Las zonas de resolución directa e inversa son independientes y es responsabilidad de los administradores de los servidores DNS que dichas zonas contengan información coherente y que no existan discrepancias.

  No es obligatorio que la entidad que administra una zona de resolución directa de un dominio tenga que administrar la zona de resolución inversa que se corresponda con las direcciones IPs asociadas a dicho dominio.
  

  ... zeppelinux.es. IN NS ns1.zeppelinux.es. ns1.zeppelinux.es. IN A 192.168.1.20 mortadelo.zeppelinux.es. IN A 192.168.1.21 filemon.zeppelinux.es. IN A 192.168.1.22 gazapo.zeppelinux.es. IN A 192.168.1.23www.zeppelinux.es. IN CNAME mortadelo.zeppelinux.es. ftp.zeppelinux.es. IN CNAME filemon.zeppelinux.es. ...

  ... zeppelinux.es. IN NS ns1.zeppelinux.es. ns1.zeppelinux.es. IN A 192.168.1.20 mortadelo.zeppelinux.es. IN A 192.168.1.21 filemon.zeppelinux.es. IN A 192.168.1.22 gazapo.zeppelinux.es. IN A 192.168.1.23 www.zeppelinux.es. IN CNAME mortadelo.zeppelinux.es. ftp.zeppelinux.es. IN CNAME filemon.zeppelinux.es. ...

  ... 1.168.192.in-addr.arpa. IN NS ns1.zeppelinux.es. 20.1.168.192.in-addr.arpa. IN PTR ns1.zeppelinux.es. 21.1.168.192.in-addr.arpa. IN PTR mortadelo.zeppelinux.es. 22.1.168.192.in-addr.arpa. IN PTR filemon.zeppelinux.es. 123.1.168.192.in-addr.arpa. IN PTR gazapo.zeppelinux.es....

  ... 1.168.192.in-addr.arpa. IN NS ns1.zeppelinux.es. 20.1.168.192.in-addr.arpa. IN PTR ns1.zeppelinux.es. 21.1.168.192.in-addr.arpa. IN PTR mortadelo.zeppelinux.es. 22.1.168.192.in-addr.arpa. IN PTR filemon.zeppelinux.es. 123.1.168.192.in-addr.arpa. IN PTR gazapo.zeppelinux.es. ...

  En función de de los dos archivos de zona (directa e inversa) mostrados arriba, vamos a analizar las siguientes preguntas:
  • Si un cliente DNS pregunta por nombre mortadelo.zeppelinux.es, el servidor DNS consultará el fichero de zona de resolución directa y devolverá la IP 192.168.1.21.
  • Si un cliente DNS pregunta por la dirección IP 192.168.1.21, el servidor DNS consultará el fichero de zona de resolución inversa y devolverá el nombre mortadelo.zeppelinux.es.
  • Si un cliente DNS pregunta por nombre gazapo.zeppelinux.es, el servidor DNS consultará el fichero de zona de resolución directa y devolverá la IP 192.168.1.23.
  • Si un cliente DNS pregunta por la dirección IP 192.168.1.23, el servidor DNS consultará el fichero de zona de resolución inversa y devolverá que no ha encontrado nada, debido a que las zonas de resolución directa e inversa no son coherentes.
  • Si un cliente DNS pregunta por la dirección IP 192.168.1.123, el servidor DNS consultará el fichero de zona de resolución inversa y devolverá el nombre gazapo.zeppelinux.es. En este caso, también, las zonas de resolución directa e inversa no son coherentes.

 

• Proceso de resolución (Volver al índice General)
  El proceso de resolución inversa es similar al de resolución directa. Las direcciones IP se tratan como nombres de dominio. Por lo tanto, existen consultas recursivas, iterativas, cache, TTL, etc.
  Por ejemplo, si un cliente DNS realiza una consulta recursiva de la IP 192.168.1.21 a un servidor DNS, éste, si no lo tiene en cache, iniciará una serie de consultas iterativas a los servidores DNS raíz, a los servidores autorizados para el dominio 192.in-addr.arpa y así sucesivamente.

 

• Delegación y resolución inversa (Volver al índice General)
  La delegación de zonas de resolución inversa cuando las máscaras de red son múltiplos de 8 (/8, /16, /24) es similar a la delegación en la resolución directa, pero cuando son máscaras de subred de tamaño variable o VLSM, por ejemplo /29, empleadas en el enrutamiento entre dominios sin clase (classless Inter-Domanin Routing o CIDR), El procedimiento es más complejo. Además, utilizar el viejo truco de utilizar registros de tipo CNAME en las zonas de resolución inversa ya no funciona, fallará la resolución inversa. Una de las soluciones es que tu ISP inserte tu registro PTR directamente en su fichero de zona sin clase en lugar del truco del registro CNAME.

  Debido a su complejidad, la delegación no se trata en este artículo.

Aquí termina el quinto de los artículos dedicado al Sistema de Nombres de Dominio (DNS). En breve, continuaremos publicando más sobre DNS, en concreto sobre Registros de recursos DNS (RR, Resource Records).
 

Espero que este artículo os haya sido de utilidad. Si pensáis que podéis colaborar para mejorar este artículo, que hay algo erróneo en él o simplemente deseáis comentarlo, por favor, dejad vuestra opinión más abajo.
  Configuración de privacidad y de cookies.