CONCEPTOS BÁSICOS DE DNS – ENTENDIENDO EL SERVICIO.
El servicio DNS (Domain Name Service) es como su nombre lo indica, un servicio que se encarga de recibir y resolver consultas de clientes que buscan determinar una dirección IP o el nombre de dominio de un sitio determinado, su principio básico es sencillo, un cliente enviá un paquete DNS al servidor con la el nombre de Dominio que desea consultar, el servidor DNS busca dicho dominio y retorna la dirección IP a la que esta asociada. Este mismo mecanismo también funciona de modo inverso, es decir, si el cliente enviá un paquete DNS con la dirección IP del dominio, el servidor DNS buscará y enviará el nombre del dominio que corresponde con la dirección IP que el usuario ha enviado.
Entrando un poco más “al detalle” del funcionamiento de un servidor DNS, es necesario conocer en primera instancia algunos términos que son importantes:
Zonas:
Las zonas son un conjunto de dominios y subdominios que son administrados por el servidor DNS, es un concepto distinto al de dominio, dado que en realidad una zona es una colección de dominios, por ejemplo, un sitio determinado tiene los siguientes registros DNS:
| http://www.domain_test.comgob.domain_test.commtv_domain_test.com |
En estos registros, las zonas son “.com”, “domain_test”, “www”, “gob”, etc. Es un concepto muy similar al de “subdominios” sin embargo la sutil diferencia esta en que un subdominio frecuentemente es parte de una zona principal, mientras que una zona es simplemente un elemento del namespace. Por otro lado la zona TLD (Top Level Domain) frecuentemente se asocia con el tipo de contenido que verá el usuario final cuando consulte el dominio, por ejemplo “.com”, “.org”, “.net”, “.edu”, etc.
NameServer:
Se trata del software responsable de dar respuesta a las peticiones DNS, tales como “cual es la dirección IP para el nombre de dominio www.xxxxx.com?” y del mismo modo responde a peticiones DNS tales como “cual es el nombre de dominio para la dirección IP XXX.XXX.XXX.XXX?
Los NameServer son el corazón de toda la arquitectura que conforma los servicios de DNS.
NameServer Autoritativo:
Cuando un NameServer recibe una petición que no puede resolver, puede tener dos opciones o retornar como respuesta al cliente que no encuentra la dirección indicada (si es desde un navegador web probablemente un error 4XX) o intentar resolver la dirección buscando en Internet, el comportamiento del servidor DNS depende de la configuración que tenga el NameServer, en el caso de que este configurado para que solamente se realicen las búsquedas en la base de datos local, es decir, en la cache del servidor DNS, la respuesta se conoce como Respuesta Autoritativa y en estos casos el servidor se conoce como NameServer Autoritativo.
NameServer Recursivo:
Si un NameServer esta configurado para que sea recursivo, este permitirá que la petición de un cliente pueda ser obtenida y completada por un servidor DNS externo, en el caso de que el DNS no pueda resolver la dirección IP o el nombre de dominio, indicará al cliente el siguiente servidor DNS en la cadena de servidores que puede resolver la dirección o nombre de dominio solicitado, en términos coloquiales, el servidor DNS responderá al cliente, “No puedo resolver la dirección o nombre de dominio solicitado, tal vez alguno de los siguientes servidores DNS pueda resolverlo, estos son los detalles” esto es lo que se conoce como un proceso de delegación de peticiones.
Resolver:
Se trata de un software que se ejecuta en el lado del cliente y es el responsable de crear y enviar a un NameServer un paquete DNS para solicitar la resolución de un nombre de dominio o dirección IP determinada, ya sea en la zona o en Internet.
Para definir el NameServer al que debe solicitar la resolución de peticiones DNS, en sistemas Windows se establecen dichos servidores en Conexiones de Red del Panel de Control, mientras que en sistemas GNU/Linux simplemente se edita el fichero /etc/resolv.conf
Registro de Recursos (RECORDS):
Aunque muchas personas piensan que DNS solamente es un servicio para la resolución de direcciones IP y Nombres de Dominio, en realidad es algo un poco más complejo que esto, dado que existen otra serie de “preguntas” que se le pueden enviar a un servidor DNS, lo que realmente convierte a DNS en una base de datos de “Registro de Recursos” distribuida.
Aunque el tipo más común es la solicitud de una dirección IP (Registro tipo A para IPv4, Registro tipo AAAA para IPv6), también existen otros registros, como por ejemplo MX (Mail Exchanger), NS (Name Server), IN (Internet), SOA(Start Of Authority), CNAME (Canonical Name) entre otras.
La siguiente tabla enseña un ejemplo de como se mapean este tipo de registros en un servidor DNS y enseña cada elemento de un dominio valido.
| WWW . GOOGLE . ORG SUB-DOMINIO/HOST DOMINIO TLD/ZONA ZONA ZONA TLD/ZONA
COOP . WWW . GOOGLE . ORG SUBDOMINIO HOST DOMINIO |
| A | IPv4 Dirección IP |
| AAAA | IPv6 Dirección IP |
| MX | MAIL Exchange |
| CNAME | Nombre Canónico / Alias |
| TXT | Texto Plano |
| NS | Name Server |
Ahora, teniendo estos conceptos claros, como es posible aplicarlos en un ejemplo? Como saber si una petición determinada es autoritativa o no autoritativa? Como saber otros detalles de un servidor DNS determinado? Para todo esto es posible utilizar una herramienta incluida en prácticamente todas las distribuciones de GNU/Linux actuales llamada NSLOOKUP, también existe otra herramienta que tiene las mismas funcionalidades y que de igual forma se encuentra incluida en una gran mayoría de distribuciones GNU/Linux llamada DIG.
AXFR
Se trata de un concepto que consiste en la “transferencia de zona” sobre un dominio dado, es decir, transferir peticiones a cada una de las zonas conocidas para un dominio determinado, (tipicamente utilizado para la sincronización entre servidores DNS Principales y Secundarios para tareas de backup) lo que permite consultar los subdominios/zonas que se encuentran configuradas en un dominio determinado. Es bastante útil especialmente cuando se desea conocer los subdominios de un dominio dado, de esta forma se pueden conocer las zonas que contempla el dominio en cuestión, esto frecuentemente es conocido como “Enumeración de DNS”
USANDO NSLOOKUP DIG
Se trata de herramientas que permite realizar consultas a servidores DNS y obtener información de ellos en función a los parámetros establecidos en cada paquete DNS enviado al servidor, para conseguir esto, nslookup cuenta con un pequeño interprete que permite establecer opciones de registros DNS, (como los que se han indicado en párrafos anteriores) y en función a dichos valores, enviar la petición al servidor(s) DNS establecido(s), mientras que en dig se estos valores se introducen directamente como parámetros adicionales del comando.
Estableciendo el servidor DNS a utilizar
| # nslookup> server 192.168.1.33 Default server: 192.168.1.33 Address: 192.168.1.33#53 >set type=a Server: 192.168.1.33 Address: 192.168.1.33#53 Non-authoritative answer: http://www.google.com canonical name = http://www.l.google.com. Name: http://www.l.google.com Address: 209.85.227.99 Name: http://www.l.google.com Address: 209.85.227.103 Name: http://www.l.google.com Address: 209.85.227.104 Name: http://www.l.google.com Address: 209.85.227.105 Name: http://www.l.google.com Address: 209.85.227.106 Name: http://www.l.google.com Address: 209.85.227.147 |
Con lo anterior se ha establecido que la búsqueda se debe hacer por medio de registros tipo A (Dirección IP bajo Ipv4)
| > set type=txt> http://www.google.com Server: 192.168.1.33 Address: 192.168.1.33#53 Non-authoritative answer: http://www.google.com canonical name = http://www.l.google.com. Authoritative answers can be found from: l.google.com origin = ns1.google.com mail addr = dns-admin.google.com serial = 1452856 refresh = 900 retry = 900 expire = 1800 minimum = 60 |
Ahora se ha establecido el Record TXT, el cual solamente consultará información del servidor DNS en formato “texto plano”
Consultas de este tipo con DIG, arrojan los siguientes resultados
| >dig mx gmail.com;
<<>> DiG 9.7.1-P2 <<>> mx gmail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19648 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. ;; AUTHORITY SECTION: com. 167527 IN NS i.gtld-servers.net. com. 167527 IN NS j.gtld-servers.net. com. 167527 IN NS l.gtld-servers.net. com. 167527 IN NS h.gtld-servers.net. com. 167527 IN NS d.gtld-servers.net. com. 167527 IN NS g.gtld-servers.net. com. 167527 IN NS e.gtld-servers.net. com. 167527 IN NS b.gtld-servers.net. com. 167527 IN NS a.gtld-servers.net. com. 167527 IN NS m.gtld-servers.net. com. 167527 IN NS f.gtld-servers.net. com. 167527 IN NS k.gtld-servers.net. com. 167527 IN NS c.gtld-servers.net. ;; Query time: 77 msec ;; SERVER: 192.168.1.33#53(192.168.1.33) ;; WHEN: Thu Jun 9 00:33:07 2011 ;; MSG SIZE rcvd: 374 |
Como puede apreciarse se ha establecido el record MX (Mail eXchange) y ha retornado una información muy detallada del dominio.
| >dig txt google.com;
<<>> DiG 9.7.1-P2 <<>> txt google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30477 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN TXT ;; ANSWER SECTION: google.com. 3600 IN TXT «v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all» ;; AUTHORITY SECTION: com. 167421 IN NS f.gtld-servers.net. com. 167421 IN NS h.gtld-servers.net. com. 167421 IN NS m.gtld-servers.net. com. 167421 IN NS k.gtld-servers.net. com. 167421 IN NS d.gtld-servers.net. com. 167421 IN NS c.gtld-servers.net. com. 167421 IN NS a.gtld-servers.net. com. 167421 IN NS b.gtld-servers.net. com. 167421 IN NS e.gtld-servers.net. com. 167421 IN NS l.gtld-servers.net. com. 167421 IN NS g.gtld-servers.net. com. 167421 IN NS i.gtld-servers.net. com. 167421 IN NS j.gtld-servers.net. ;; Query time: 139 msec ;; SERVER: 192.168.1.33#53(192.168.1.33) ;; WHEN: Thu Jun 9 00:34:53 2011 ;; MSG SIZE rcvd: 346 |
La consulta anterior envía la petición con el record TXT, al igual que se ha hecho anteriormente con nslookup.
Por otro lado, como se ha mencionado anteriormente con el tipo AXFR es posible realizar una consulta sobre los sub-dominios que soporta un dominio, para esto se emplea el comando DIG de la siguiente forma:
| dig -t AXFR linux.lan
@ns1.linux.lan; <<>> DiG 9.7.1-P2 <<>> -t AXFR linux.lan @ns1.linux.lan ;; global options: +cmd linux.lan. 38400 IN SOA ns1.linux.lan. admin.linux.lan. 2006081401 28800 3600 604800 38400 linux.lan. 38400 IN MX 10 mail.linux.lan. linux.lan. 38400 IN NS ns1.linux.lan. IN.linux.lan. 38400 IN NS http://www.tunnel.linux.lan. mail.linux.lan. 38400 IN A 192.168.1.33 mail.linux.lan. 38400 IN MX 10 mail.linux.lan. ns1.linux.lan. 38400 IN A 192.168.1.33 sshdns.ns1.linux.lan. 38400 IN A 192.168.1.33 http://www.tunnel.linux.lan. 38400 IN A 192.168.1.33 http://www.linux.lan. 38400 IN A 192.168.1.33 linux.lan. 38400 IN SOA ns1.linux.lan. admin.linux.lan. 2006081401 28800 3600 604800 38400 ;; Query time: 1 msec ;; SERVER: 192.168.1.33#53(192.168.1.33) ;; WHEN: Thu Jun 9 00:45:58 2011 ;; XFR size: 11 records (messages 1, bytes 279) |
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 