[ubuntu-ar] [OT] Limpiar cache del proxy del ISP

Mariano Absatz el.baby at gmail.com
Mon Jul 6 03:51:30 BST 2009


2009/7/3 Daniel Garnero <eldanigarnero at gmail.com>

> El vie, 03-07-2009 a las 14:51 -0300, Mariano Absatz escribió:
>
> >
> > De todos modos, si tu punto es que vos qerés un servicio DNS confiable
> > y no confiás en el de tu ISP (y hacés bien), dado que tenés la suerte
> > de tener un equipo linux, podés instalarte un resolver DNS local y
> > chau pichi.
> >
> > ..............................
> >
>
> Interesante, muy interesante planteo, Mariano :) Nunca pensé esta
> posibilidad, así que me tomaré el Fin de Semana para estudiar un poco
> mejor el tema. En principio, me parece una posibilidad piola; para
> aprender y para experimentar. Pero casi de manera automática aparece la
> pregunta: ¿Qué ventaja tiene armar un "resolvedor de nombres" frenta al
> uso de los DNS de OpenDNS, por ejemplo? Pregunto para no perderme parte
> de las justificaciones...


Mal y pronto (un curso de DNS ya es un OT del OT, creo)...

cuando un programa necesita obtener la IP en base a un nombre, llama a una
librería local de resolución de nombres que, según como esté configurado el
servicio de nombres (en /etc/nsswitch) se fijará en el archivo /etc/hosts,
en el servicio NIS si lo tenés instalado o en el DNS...

El DNS, normalmente, consulta a un "resolver recursivo" que figura en el
archivo /etc/resolv.conf.

Este resolver se llama "recursivo" porque contesta lo que en DNS se llaman
consultas recursivas que son del tipo "decíme quién es www.linkedin.com y si
no lo sabés, averigualo en donde haga falta y decimelo".

Suponiendo que el servidor en cuestión no tiene ni idea de quién es
www.linkedin.com tiene que empezar a a buscar en la "raíz" del DNS (la raíz
es un "." a la derecha de todos los nombres que en general no se escribe).
Esto en general se resuelve con una lista puesta a mano en el server que
dice cuáles son los servidores raíz autoritativos (esto es una lista de
servidores que saben cuáles son los servidores de todos y cada uno de los
"top level domains": .com, .edu, .gov, .ar, .br, .es, etc... esto es todos
los dominios que van "a la derecha de todo" en los nombres de dominio).

1) El server recursivo agarra uno (o más) de esta lista y le dice "che,
¿quién es www.linkedin.com?"

Cualquiera de los servidores raíz le responderá, "no sé, pero todos estos
servidores son autoritativos para los dominios ".com", preguntales a ellos"
(y le pasa una lista de los servers de .com).

2) Entonces el server recursivo agarra uno (o más) de esta nueva lista y le
dice "che, ¿quién es www.linkedin.com?"

Cualquiera de los servidores de .com le responderá "no sé, pero todos estos
servidores son autoritativos para el dominio "linkedin.com", preguntales a
ellos" (y le pasa una lista de los servers de linkedin.com).

3) Entonces el server recursivo agarra uno (o más) de esta nueva lista y le
dice "che, ¿quién es www.linkedin.com?"

Y el que sea le debería contestar directamente la dirección (o direcciones)
de www.linkedin.com

Si querés jugar a hacer esto a mano podés probar:

0) dig . ns
eso te va a devolver una lista de servers A.ROOT-SERVERS.NET,
B.ROOT-SERVERS.NET, etc.. que son los "root name servers"

1) elegí cualquiera y probá:
dig @a.root-servers.net A www.linkedin.com
(o sea, preguntarle a a.root-servers.net cuál es la dirección (A) de
www.linkedin.com)
te va a devolver una lista de servers A.GTLD-SERVERS.NET, B.GTLD-SERVERS.NET,
etc. que son los servidores autoritativos de ".com".

2) elegí cualquiera y probá
dig @d.gtld-servers.net a www.linkedin.com
(o sea, pregutarle a d.gtld-servers.net cuál es la dirección de www.,
linkedin.com).
a mí me devolvió la siguiente lista:
linkedin.com.        172800    IN    NS    pdns1.ultradns.net.
linkedin.com.        172800    IN    NS    pdns2.ultradns.net.
linkedin.com.        172800    IN    NS    pdns3.ultradns.org.
linkedin.com.        172800    IN    NS    pdns4.ultradns.org.
linkedin.com.        172800    IN    NS    pdns5.ultradns.info.
linkedin.com.        172800    IN    NS    pdns6.ultradns.co.uk.

o sesa, que esos 6 son los servidores de nombres autoritativos de "
linkedin.com"

3) elegí cualquiera y probá:
dig @pdns3.ultradns.org a www.linkedin.com

Esto finalmente contesta nuestra pregunta:
www.linkedin.com.    21600    IN    A    64.74.98.80

La dirección (A) de www.linkedin.com es 64.74.98.80




Suponiendo que el único server web en esa dirección sea el de linkedin (y
que no tenga servidores virtuales por nombre), podrías bajarte la home de
linkedin "a lo bestia" haciendo lo siguiente:

$ telnet 64.74.98.80 80


y cuando se conecta le decís
GET /

pero eso mejor se lo dejamos al firefox...

De hecho... si sigue sin andarte linkedin, fijate qué pasa si en el browser
probás http://64.74.98.80

Saludos.


-- 
Mariano Absatz - El Baby
www.clueless.com.ar
#########################

"I may be drunk, Miss, but in the morning I will be sober and you will still
be ugly." - Wins...<http://quotesdaddy.com/quote/280685/winston-churchill/i-may-be-drunk-miss-but-in-the-morning-i-will-be-sober>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-ar/attachments/20090705/bfddaa53/attachment.htm 


More information about the Ubuntu-ar mailing list