Ejercicio DNS: dig, parte 2 ==================================================== No necesita ser root para hacer este ejercicio. NOTA: es buena idea poner un punto al final de cada dominio - esto evita que el dominio por defecto en `/etc/resolv.conf` sea agregado autom‡ticamente. Por ejemplo: probando __www.tiscali.co.uk.__ Para este ejercicio, necesitamos cambiar temporalmente su servidor por defecto, configurado en /etc/resolv.conf, a 10.10.0.254, as’: # ee /etc/resolv.conf y configure el servidor como sigue: nameserver 10.10.0.254 Guarde el fichero y salga del editor. Nota: Esto es neceario, de lo contrario no podremos hacer peticiones hacia la Internet. 1. Haga una petici—n comenzando por un servidor ra’z --------------------------------------------- Los servidores ra’z se llaman `[a-m].root-servers.net.` Elija cualquiera para empezar. $ dig +norec @f.root-servers.net. www.tiscali.co.uk. a ; <<>> DiG 9.7.2-P3 <<>> +norec @a.root-servers.net. www.tiscali.co.uk. a ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8712 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 14 ;; QUESTION SECTION: ;www.tiscali.co.uk. IN A ;; AUTHORITY SECTION: uk. 172800 IN NS ns1.nic.uk. uk. 172800 IN NS ns2.nic.uk. uk. 172800 IN NS ns3.nic.uk. uk. 172800 IN NS ns4.nic.uk. uk. 172800 IN NS ns5.nic.uk. uk. 172800 IN NS ns6.nic.uk. uk. 172800 IN NS ns7.nic.uk. uk. 172800 IN NS nsa.nic.uk. uk. 172800 IN NS nsb.nic.uk. uk. 172800 IN NS nsc.nic.uk. uk. 172800 IN NS nsd.nic.uk. ;; ADDITIONAL SECTION: ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2 ns1.nic.uk. 172800 IN A 195.66.240.130 ns2.nic.uk. 172800 IN A 217.79.164.131 ns3.nic.uk. 172800 IN A 213.219.13.131 ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83 ns4.nic.uk. 172800 IN A 194.83.244.131 ns5.nic.uk. 172800 IN A 213.246.167.131 ns6.nic.uk. 172800 IN A 213.248.254.130 ns7.nic.uk. 172800 IN A 212.121.40.130 nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3 nsa.nic.uk. 172800 IN A 156.154.100.3 nsb.nic.uk. 172800 IN A 156.154.101.3 nsc.nic.uk. 172800 IN A 156.154.102.3 nsd.nic.uk. 172800 IN A 156.154.103.3 ;; Query time: 8 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Tue Feb 15 15:53:13 2011 ;; MSG SIZE rcvd: 497 Nota: S—lo obtuvimos rŽcords NS (m‡s informaci—n relacionada - los records A que corresponden a estos servidores de nombres). Esto se conoce como una referencia (REFERRAL). En teor’a deber’amos repetir esto con `b.root-servers.net`, `c.root-servers.net` ... y revisar todas las respuestas. Ocasionalmente usted _podr’a_ notar inconsistencias entre los servidores ra’z, pero ser’a muy raro. 2. F’jese en los 11 servidores que obtuvimos en la respuesta -------------------------------------------------------------- (Recuerde que DNS no distingue entre mayœsculas y minœsculas. Adem‡s, los recibimos en orden aleatorio; esto no importa porque vamos a probarlos todos de cualquier manera) ns1.nic.uk. ns2.nic.uk. ns3.nic.uk. ns4.nic.uk. ns5.nic.uk. ns6.nic.uk. ns7.nic.uk. nsa.nic.uk. nsb.nic.uk. nsc.nic.uk. nsd.nic.uk. 3. Repita la petici—n para cada servidor NS ---------------------------------------------- $ dig +norec @ns1.nic.uk. www.tiscali.co.uk. a ; <<>> DiG 9.7.2-P3 <<>> +norec @ns1.nic.uk. www.tiscali.co.uk. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28452 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.tiscali.co.uk. IN A ;; AUTHORITY SECTION: tiscali.co.uk. 172800 IN NS ns0.as9105.com. tiscali.co.uk. 172800 IN NS ns0.tiscali.co.uk. ;; ADDITIONAL SECTION: ns0.tiscali.co.uk. 172800 IN A 212.74.114.132 ;; Query time: 20 msec ;; SERVER: 195.66.240.130#53(195.66.240.130) ;; WHEN: Mon May 16 12:37:23 2005 ;; MSG SIZE rcvd: 97 $ dig +norec @ns2.nic.uk. www.tiscali.co.uk. a ... $ dig +norec @ns3.nic.uk. www.tiscali.co.uk. a ... ... etc *Revise que los resultados son consistentes!* Nota: Si un servidor es autorizado para el dominio como para el sub-dominio, retornar‡ inmediatamente el resultado para el sub-dominio. Esto es normal. En este ejemplo, los mismos servidores son autorizados para ambos `.uk` y `.co.uk`, por lo tanto pueden referirnos inmediatamente a `tiscali.co.uk`, mov’endonos dos niveles hacia abajo en la jerarqu’a de un golpe. Puede ver aqu’ que estamos recibiendo otra delegaci—n, esta vez a otros dos servidores: > ns0.as9105.com > ns0.tiscali.co.uk 4. Repita la misma petici—n con todos los servidores NS del paso 3 ------------------------------------------------------------------ $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a ; <<>> DiG 9.7.2-P3 <<>> +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52841 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.tiscali.co.uk. IN A ;; ANSWER SECTION: www.tiscali.co.uk. 300 IN A 212.74.99.30 ;; AUTHORITY SECTION: tiscali.co.uk. 3600 IN NS ns0.tiscali.co.uk. tiscali.co.uk. 3600 IN NS ns0.as9105.com. ;; ADDITIONAL SECTION: ns0.as9105.com. 604800 IN A 212.139.129.130 ns0.tiscali.co.uk. 604800 IN A 212.74.114.132 ;; Query time: 322 msec ;; SERVER: 212.74.114.132#53(212.74.114.132) ;; WHEN: Tue Feb 15 16:01:04 2011 ;; MSG SIZE rcvd: 129 $ dig +norec @ns0.as9105.com. www.tiscali.co.uk. a ... ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ... ;; ANSWER SECTION: www.tiscali.co.uk. 300 IN A 212.74.99.30 Esta vez, en lugar de recibir otra delegaci—n, hemos encontrado la respuesta que busc‡bamos. F’jese que amobos servidores est‡n dando respuestas autorizadas (`flags: aa`), y que los resultados son iguales. TambiŽn observe que la secci—n 'AUTHORITY SECTION' en la respuesta tienen la *misma* lista de servidores que usamos para hacer la petici—n. (Este segundo conjunto de servidores NS est‡n contenidos en los servidores autorizados, al contrario de la delegaci—n desde m‡s arriba) Pista: pruebe esto: $ dig + nssearch tiscali.co.uk 5. Lista de comprobaci—n ------------------------- * Pudo alcanzar todos los servidores? * Hab’a al menos dos servidores en subredes distintas? * Todos dieron o una referencia o una AA (Authoritative Answer)? * Fueron iguales todas las respuestas? * Los valores de TTL eran razonables? * Era igual la lista de servidores finales en la AUTHORITY SECTION que en la delegaci—n? 6. Ahora, revise los rŽcords NS! --------------------------------------- Recuerde que cada record NS contiene el nombre de un nodo, no una direcci—n IP. (No est‡ permitido apuntar un NS record a una IP, no va a funcionar) Pero, cuando ejecut‡bamos algo como `dig @ns0.as9105.com ...`, est‡bamos depeniendo de que dig hiciera una bœsqueda del rŽcord tipo A. De hecho, est‡bamos haciendo dos peticiones: - dig pregunta por la direcci—n IP de ns0.as9105.com, haciendo una bœsqueda recursiva usando el servidor configurado en /etc/resolv.conf - Una vez encontrada la direcci—n IP, dig puede enviar la petici—n a dicho servidor Por lo tanto, necesita empezar de nuevo y revise cada record NS entontrado, a partir de la ra’z, exatamente de la misma manera! Esto es tedioso, y generalmente los servidores ra’z est‡n correctos. Pero vale la pena revisar los records NS del pa’s y bajar hasta los suyos propios. Por ejemplo: revisar ns0.as9105.com $ dig +norec @a.root-servers.net. ns0.as9105.com. a ... referencia a [a-m].gtld-servers.net. $ dig +norec @a.gtld-servers.net. ns0.as9105.com. a ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; ANSWER SECTION: ns0.as9105.com. 172800 IN A 212.139.129.130 <==== ;; AUTHORITY SECTION: as9105.com. 172800 IN NS ns0.as9105.com. as9105.com. 172800 IN NS ns0.tiscali.co.uk. F’jese que obtuvimos una respuesta - peno no es autorizada! (Adem‡s del faltante 'aa', observe que el servidor que interrogamos no es uno de los nodos listados en la 'authority section') Esto no es un error, siempre que la informaci—n sea correcta - se llama un "glue record" (record pegamento), que veremos m‡s tarde - pero necesitamos continuar camino abajo en la jerarqu’a: $ dig +norec @ns0.as9105.com. ns0.as9105.com. a ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; ANSWER SECTION: ns0.as9105.com. 2419200 IN A 212.139.129.130 <==== ;; AUTHORITY SECTION: as9105.com. 600 IN NS ns0.tiscali.co.uk. as9105.com. 600 IN NS ns0.as9105.com. ;; ADDITIONAL SECTION: ns0.tiscali.co.uk. 2419200 IN A 212.74.114.132 $ dig +norec @ns0.tiscali.co.uk. ns0.as9105.com. a ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; ANSWER SECTION: ns0.as9105.com. 2419200 IN A 212.139.129.130 <==== ;; AUTHORITY SECTION: as9105.com. 600 IN NS ns0.tiscali.co.uk. as9105.com. 600 IN NS ns0.as9105.com. ;; ADDITIONAL SECTION: ns0.tiscali.co.uk. 2419200 IN A 212.74.114.132 Ahora compruebe: * Fueron iguales todas las respuestas? (S’: 212.139.129.130 en `a.gtld-servers.net` y los servidores autorizados) * Hubo concordancia entre los records NS de la delegaci—n y de los autorizados? (S’: delegaci—n a `ns0.as9105.com` y `ns0.tiscali.co.uk`, y estos mismos records aparecen en la 'authority section' de la respuesta final) El significado de NOERROR -------------------------- Puede que se haya fijado en el campo de "status: " en la salida de dig: status: NXDOMAIN o status: NOERROR NXDOMAIN significa "dominio no-existente" (Non-eXistent Domain). Quiere decir: "Lo sentimos, no hay informaci—n acerca del nombre en cuesti—n". Por ejemplo: $ dig +norec @ns0.tiscali.co.uk. wibble.tiscali.co.uk. a É retornar‡ NXDOMAIN. No hay nada en el dominio tiscali.co.uk con el nombre "wibble". Ningœn rŽcord A, o AAAA, etcÉ Bien, puede que tambiŽn haya notado que la secci—n ANSWER puede contener 0 respuestas, pero aœn as’, el servidor retorna "NOERROR", y no "NXDOMAIN". Por quŽ? Digamos, por ejemplo, que queremos saber la direcci—n IP de www.tiscali.co.uk: $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a Todo bien. Deber’a ver lo siguiente: status: NOERROR ANSWER: 1 Ahora, preguntemos por un tipo de record *diferente* (conocido como tipo de record de recurso, "resource record type", para ser precisos): $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. txt Note que pedimos por un rŽcord TXT bajo el nombre "www.tiscali.co.uk." QuŽ obtenemos? status: NOERROR ANSWER: 0 C—mo puede ser? NOERROR en este caso significa "Lo sentimos, no existe informaci—n sobre el NOMBRE Y TIPO de record solicitado. Aj‡! Aqu’ nos est‡n diciendo que no existe un rŽcord tipo TXT para www.tiscali.co.uk - pero que puede haber informaci—n bajo otros tipos de records. De hecho, ya lo sabemos gracias a la solicitud anterior: $ dig +norec @ns0.tiscali.co.uk. www.tiscali.co.uk. a É que nos proporciona la direcci—n IP de tal nombre. Por lo tanto, un nombre no existente (NXDOMAIN) o una respuesta vac’a (NOERROR + ANSWER: 0) es aœn una respuesta, y es necesario almacenar (cache) esto, como veremos m‡s abajo. Respuestas negativas -------------------- La no-existencia de un record tambiŽn es informaci—n importante. La respuesta obtenida deber’a ser algo como: $ dig +norec @ns0.tiscali.co.uk. wibble.tiscali.co.uk. a ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51165 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; AUTHORITY SECTION: tiscali.co.uk. 3600 IN SOA ns0.tiscali.co.uk. hostmaster.talktalkplc.com. 2011012703 10800 3600 604800 3600 El bit AA est‡ activado, pero no hay nada en la respuesta aparte del SOA. Los par‡metros en el SOA se usan para saber quŽ tanto tiempo se pueden almacenar (cache) las respuestas negativas. Significado de las banderas (flags) (RFC 1034/RFC 1035) ----------------------------------------- QR Campo de un bit que especifica si este mensaje es una solicitud (0), o una respuesta (1). AA Respuesta Autorizada - este bit es v‡lido en respuestas, y especifica que el servidor que responde est‡ autorizado para el nombre de dominio en la secci—n de pregunta. RD Recursi—n Deseada - este bit se puede marcar en la solicitud y se copia en la respuesta. Si RD est‡ activado, indica al servidor que haga la petici—n de manera recursiva. El soporte para solicitudes recursivas es opcional. RA Recursi—n Disponible - este bit se marca en una respuesta e indica si existe soporte para recusi—n en el servidor. Adem‡s del bit 'AA', una alternativa para descubrir si una respuesta est‡ almacenada (en la cachŽ) es repetir la solicitud varias veces y observar el valor del TTL decrementando: $ dig psg.com. ;; ANSWER SECTION: psg.com. 14397 IN A 147.28.0.62 ^^^^^ $ dig psg.com. ;; ANSWER SECTION: psg.com. 14384 IN A 147.28.0.62 ^^^^^ Otras opciones de dig ------------------ Otras opciones de dig que le ser‡n œtiles - utilce el manual (man dig) para saber quŽ hacen: dig +tcp dig +trace Y pruebe las otras opciones que aparecen en el manual! Para concluir ------------- Recuerde restaurar la configuraci—n de /etc/resolv.conf: nameserver 10.10.0.230