sábado, diciembre 18, 2010

Una llamada a las armas (I): DNS

En Constructive Direct Action Against Censorship, la Electronic Frontier Foundation (EFF) nos propone 4 proyectos de lucha contra la censura en Internet. No son manifiestos, no son ataques de denegación de servicio distribuidos (DDoS), ni tampoco son pérdidas de tiempo como llamar a acciones "en el mundo real". Las propuestas son:

Voy a contextualizar y analizar cada una de las propuestas (excepto Tor, sobre la que no tengo nada que decir). Como se va a alargar, voy a hacerlo en varias partes, manteniendo esta cabecera en cada entrada.


The Dot-P2P Project:  a raiz del borrado del dominio Wikileaks.org se puso de manifiesto uno de los grandes cuellos de botella de la Internet actual: la gestión de nombres de dominio está centralizada en una organización, la ICANN, que supuestamente debería conducirse de forma neutral, pero que ha demostrado todo lo contrario cediendo a las presiones de un gobierno concreto. Pero aun hay más: nuevas leyes promulgadas en EE.UU. están resultando en embargo de nombres de dominio a páginas acusadas de "piratería", como es este caso, con el agravante de que las acusaciones vienen de un país diferente.

Se podrían poner más ejemplos, pero ya habéis captado la esencia del problema: InterNIC (que es como históricamente se ha llamado a los servidores raiz ahora gestionados por la ICANN) ya no es fiable. La primera solución obvia que se le ocurre a cualquiera es precisamente cambiar la autoridad de los servidores raiz. Al fin y al cabo, nadie ha escrito en piedra que los root-servers de Internet (aquellos de los que al final depende la resolución de los nombres de dominio) tengan que ser los 13 de InterNIC. Y por eso, desde hace tiempo existen algunas raices DNS alternativas. Por desgracia, estas alternativas son escasamente populares y no parece que amenacen la hegemonía de InterNIC/ICANN, aunque yo por si acaso ya estoy usando los servidores raiz de OpenNIC (si no eres de OpenNIC, ese enlace no te funcionará, puedes consultar más sobre ellos aquí o en Wikipedia), la más popular de las poco populares alternativas.

Otra de las pegas de OpenNIC y otras raices alternativas es que realmente sólo gestionan dominios de alto nivel alternativos (como .free, .geek, .indy, .oss, etc), mientras que para los "7 grandes" (ahora son más) dominios de alto nivel, más los dominios nacionales se limitan a copiar los registros de InterNIC. Es decir, que los típicos .com, .org, .net, y compañía, siguen resolviéndose como hasta ahora, y lo único que se gana son los nuevos dominios de alto nivel gestionados por OpenNIC. Estos dominios son gratuitos (no son el gran negocio de los dominios que se ha montado la ICANN), sin embargo, sigue siendo una entidad centralizada quien los gestiona. Particularmente, me molesta además que, por ejemplo, haya que dar datos personales (como una dirección o un teléfono) para registrar un dominio (por eso no he registrado ninguno).

Volvamos al proyecto dotP2P. En este estado de cosas, y con la censura del dominio de Wikileaks y la posterior reacción popular creando subdominios apuntando a sus direcciones IP, uno de los cofundadores de The Pirate Bay lanza una propuesta de crear un sistema DNS libre alternativo al de  ICANN. Entre otras cosas se quiere que sea un sistema distribuido, para que no pueda sufrir ataques de denegación de servicio como los que estaba sufriendo el DNS de Wikileaks, y para ello se propone usar protocolos P2P. Todo esto se canaliza —se esta canalizando, puesto que está en plena fase de formación— en lo que bautiza como Dot-P2P. En la web podéis ver un wiki con las líneas en las que se están trabajando.

He de decir que mi primera reacción fue de escepticismo. Escepticismo porque el DNS es ya un sistema distribuido de por sí. Sin embargo, es cierto que tiene algunos cuellos de botella atacables. El primero y obvio es el de la gestión: es centralizada, y por lo tanto dependiente del "buen comportamiento" de la organización que la realiza. El segundo, menos obvio, es cada propio nodo de la estructura de DNS empezando por los propios root-servers, que si bien pueden ser replicados y reforzados, no es algo que se haga automática y dinámicamente, y por lo tanto no es algo que se defienda bien de ataques DDoS (la mejor defensa contra un ataque distribuido es una defensa distribuida).

Así que una vez pasado mi escepticismo inicial, reconozco que un sistema de resolución de nombres descentralizado y P2P no es una mala idea. Lo que ya no me parece tan buena idea son algunas de las decisiones que se están tomando ahora mismo dentro de dotP2P:
  • Se ha escogido mantener la gestión de dominios centralizada (al parecer, pese a las protestas de un sector)
  • Se ha escogido seguir dependiendo de unos root-servers estáticos, en este caso de los de OpenNIC, que delegarían la zona .p2p a los servidores de esta red (no está muy claro cómo ni a cuáles)
En todo éste lío creo que lo primero es tener claro qué es lo que se pretende. Y lo que se pretende (en mi opinión) es resolver 2 problemas diferentes:

  1. Por un lado, una gestión descentralizada de los nombres de dominio
  2. Por otro, un sistema de resolución de nombres a IPs distribuido y probablemente dinámico.
Para el primer problema, sólo hay una manera de convertir una autoridad centralizada en una distribuida, y es una Web of Trust. Pero como eso transciende el problema del DNS, lo voy a dejar estar de momento.

En cuanto al segundo problema, lo que debemos plantearnos para empezar es si queremos mantener el viejo sistema del DNS. El DNS es una estructura jerárquica, y plasmarla mediante una estructura horizontal va a llevar a ciertos problemas de "impedancia" entre modelos. Por otro lado, se pueden plantear enfoques mucho más radicales:
  • los nombres para identificar máquinas (al menos a primer nivel) no son jerárquicos. Esto significa que, por poner un ejemplo, mi nombre de máquina (o mejor, dominio) no sería "jcantero.org" o "jcantero.com" o "jcantero.algo"; sería "jcantero". No hay necesidad de fragmentar en grandes grupos tipo "org" o "com", que son cuellos de botella y que además no reflejan ninguna subdivisión real. Podría pensarse en una subdivisión geográfica "jcantero.es", pero entonces tenemos el problema de que es una división arbitraria, no balanceable y que aporta datos privados que igual no queremos dar. Tendría mucho más sentido subdividir, por ejemplo, por comunidades virtuales ("jcantero.ecol").
  • El resolutor de nombres P2P no tiene por qué pasar por el sistema DNS. Puede usar su propio sistema P2P para resolver el nombre, sin consultar servidores raiz ni bajar por los nodos. Si estás en una red que no controlas, el que las peticiones pasen por el sistema DNS tiene la ventaja —no en todos los casos— que los firewalls y demás filtros permiten esas conexiones y puede que tengas permitido resolver peticiones DNS aunque no puedas abrir otro tipo de conexiones. Pero tiene la desventaja que se puede manipular (incluyendo filtrar) en el camino los paquetes de DNS. Si el resolutor es un cliente P2P, mientras puedas abrir algún tipo de conexión con la red P2P podrás resolver nombres, y si fuera necesario las comunicaciones podrían ir cifradas para garantizar su integridad.
  • Si por las razones que fueran se decide que el sistema debe responder al protocolo DNS (es decir, ser un backend DNS en su conjunto), si se quiere que participen masivamente servidores para que la red sea robusta ante ataques, debe permitirse la participación de servidores residentes en IPs dinámicas, incluso detrás de NATs. Ello plantea una serie de desafíos, puesto que tanto el protocolo DNS en sí como los servidores DNS tal y como estan programados hoy en día, estan pensados para un universo de IPs estáticas que cambian muy poco en el tiempo.
  • Si ni siquiera se cumple la condición anterior, entonces simplemente estamos hablando de la delegación del top level domain .p2p a una serie de servidores con IP estática bien conocidos, cuya única ¿ventaja? es que intercambian los ficheros de zona vía P2P, entonces estamos hablando de una solución no muy, y también un poco "más de lo mismo" respecto a lo que ya hay. No significa que no pueda ser interesante, pero no va mucho más allá de lo que OpenNIC puede ofrecer, por ejemplo.
Bien, ahora es cuando podéis decirme "Si eres tan listo, show us the code"; "Muéstranos cómo lo harías tú". Reconozco que no tengo un diseño hecho —aunque le haya dado algunas vueltas en la cabeza—, así que no puedo dar mi solución. Si es que a alguien le interesara, que esa es otra. Pero es que también hay que plantearse si estamos enfocando bien el problema. ¿Este es un asunto que se circunscribe estrictamente al DNS? Más adelante veremos que no, y que por ello tal vez no conviene pararse a pensar mucho en resolver un detalle, cuando hay que resolver un problema mucho más global.

9 comentarios:

Juan Luis Chulilla dijo...

Javier, evitar la censura puede que llegue a dejar de ser un problema si nuestras amables élites empiezan a ver Internet como El Problema. Cuando los que estamos en la Red dejamos de depender del bombardeo constante de sus periódicos, eso puede llegar a ser preocupante. Véase p.e. el acuerdo entre todos los periódicos respecto a los controladores, y lo que se podía leer en Internet dedicando un poco de tiempo.

No quiero caer en la conspiranoia sin necesidad, pero a lo mejor lo que dice la EFF se queda corto y hay que recurrir a herramientas más radicales como freenet (o un ejemplo más avanzado), la extensión de Guifi.net, GPG,... no sé, ¿exagero?

Lo pregunto con sinceridad, no tengo claridad de ideas a este respecto

Javier Cantero dijo...

Juan Luis, estamos de acuerdo, pero es que no me has dejado ni empezar. :-)

andoni dijo...

Yo veo una parte muy sencilla y otra muy compleja... Para empezar no es necesario replicar internic, basta con que los usuarios pongamos como primer DNS el alternativo que se pueda crear y como segundo uno de internic para resolver todo lo que ya existe y no perder información, ahora bien, ¿Cómo hacer para no tener que usar una sola ip como server dns y no se produzcan cuellos de botella? Yo apuesto por una aplicación que esté conectada a una red p2p y que a través de esta red vayan llegando diferentes direcciones IP de servidores de nuestro sistema alternativo, y que la aplicación escriba directamente en el resolv las ip-s dos sevidores de nombres (de los alternativos se entiende) y que cada hora o así se actualice para asegurar un buen funcionamiento, no sé que os parece, es una idea.

Javier Cantero dijo...

@andoni, se ponen varios DNS en el resolv.conf por si acaso alguno está caído o saturado, pero no existe prioridad en los DNS indicados en el resolv. Vamos, no tienen porqué leerse en orden.

En cuanto a actualizar las IPs directamente en el resolv.conf: estoy suponiendo que los servidores DNS son de pares, no servidores estables con IPs fijas (porque para eso no hace falta andar cambiando los DNSs), así que... ¿y si las dos IPs justo se desconectan en el periodo de esa hora? Te quedas sin DNS, con lo cual hasta puede que te quedes sin poder acceder a quién te tiene que proporcionar nuevas IPs... Te quedarías desconectado de la red de resolución de nombres.

andoni dijo...

javier, en linux cuanto menos se pueden priorizar los DNS yo por ejemplo primero tiro de 127.0.0.1 y si no lo encuentra tiro de externos, con respecto a que las máquinas puedan apagarse a la vez y perder el servicio de nombres, el programa puede tener un watchdog que lo compruebe y que lo cambie en caso de que caiga.

Javier Cantero dijo...

@andoni: ¿Pero lo cambia por cual? Ese es el problema.

andoni dijo...

javier, pues a cualquier otra máquina conectada a la red p2p la idea es que la aplicación a la que me refiero haga de cliente y de servidor...

Javier Cantero dijo...

@andoni: al final estás haciendo un cliente de resolución que es a la vez un cliente (y servidor) P2P de la red de resolución de nombres. Una vez que tienes acceso a la red, no te hace falta resolver los nombres de la zona (por ejemplo .p2p) a través del DNS normal, te lo puede resolver el propio sistema P2P. Y los watchdogs son el equivalente a tener conexiones con otros pares en la red P2P.

Maximiliano dijo...

OpenNIC de hecho no es centralizado, ya que permite el ingreso de nuevas entidades, lo que hacen es usar el peering, osea asociarse con la otra entidad, actualmente está en proceso aliarse con .42 .p2p y protanemte con UnifiedRoot