Apunte de Clase del 24/10/2007 (Teoría de las Comunicaciones)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

DNS[editar]

Esto no está en el Peterson. Sí está en el Tanenbaum.

Tengo la siguiente dir:

http://www.tcpipguide.com/

Desde www hasta com tengo una dirección IP. Después tengo el port. Acá está implícito, pero por ser http todos sabemos que el puerto default es 80.

Dos funciones principalmente:

  1. Le pregunto cuál es la dirección IP dada una URL.
  2. Puedo llamar a distintas direcciones IP con el mismo nombre, por lo que me da mayor flexibilidad.

Ahora explica el flujo desde que el usuario ingresa una dirección hasta que se accede al recurso. El flujo está graficado en la diapositiva Internetwork Access With A Name System.

Hay dos facetas a tener en cuenta:

  1. Cómo resuelvo direcciones dado un nombre?
  2. Cómo le ingreso los datos al sistema de forma distribuída y garantizando buena performance, unicidad, etc.?

Cómo es un nombre?

Flat Name Architecture:

Ejemplo: un número de documento, porque es secuencial, no tiene ningún tipo de estructura.

Hierarchical Name Architecture: ejemplo: un número de teléfono, donde tengo un código de área que me indica el área, una característica que me indica la central, y el número particular para identificar una línea dentro de la central.

En DNS se decidió que los nombres sean jerárquicos.

Cada máquina al principio tenía un archivito que mapeaba IPs a nombres. Cuando Internet era muy chiquita, con esto no había problema, pero en cuanto empezó a crecer, cagamos la fruta.

Todas las noches las máquinas se actualizaban las tablas desde un servidor centralizado.

Tarda en actualizarse, y cuando hay muchas máquinas el tráfico se hace enorme.

No es escalable.

DNS sí es escalable. Aguante DNS.

Ahora dan el Namespace tree de DNS. Está en la diapositiva: DNS Name Space Tree and Domain-Related Terminology.

La unicidad se garantiza porque hay una única entidad que controla cada pedazo de dirección. Por ejemplo, hay unos tipos que controlan todos los nombres que terminan en .com.

En un nombre www.pedorcha.com, com es la raíz del nombre, pedorcha el segundo nivel y www es la hoja. Los que controlan pedorcha controlan todos los nombres a la izquierda de pedorcha.

Los roots de los dominios se trataban de mapear de acuerdo al tipo de entidad que pone un site (si es el ejército va a parar a un .mil, si es comercial a .com, si es una universidad, escuela, etc. es .edu, and so on). En la práctica el que tiene el poder decide.

Charla sobre la relación en tre la política, el dinero y el poder y tener buenos dominios, cortitos y con la menor cantidad de prefijos posibles. Por ejemplo, en uba.ar somos pulenta.

Hay una entidad en cada zona que administra y deccide que nombres se pueden usar y dan de alta/baja los dominios El sufijo de país no necesariamente indica dónde está el servidor. Cada zona a su vez puede decidir si usa .com o .co, o no usa nada (como españa), depende de la autoridad a cargo.

Concepto de "Zona": Es un subárbol dentro del árbol total, que queda a cargo de una autoridad que administra desde la raíz del subárbol para abajo, y probablente pondrá un software para que cumpla funciones similares a las de un DNS. Cómo se corta el árbol en zonas depende. A su vez una zona podría delegar un subárbol de la misma a otra subzona.

NO HAY UNA RELACIÓN ENTRE LOS DOMINIOS Y LAS DIRECCIONES IP DE RED A RED. Se aplica nuevamente, por ejemplo, a los fufijos de país.

Si yo hago un trace de www.inti.gov.ar y veo que pasa por una página aparentemente de EEUU no me dice nada. Por emepezar el dominio .com no garantiza que la pc está en EEUU. Además, podría salir al exteior y volver a entrar. En definitiva, no es garantía de nada.

Se definen las zonas. En cada una de ellas tiene que haber un sistema/autoridad que tenga la información de la zona. La idea de DNS es que siempre se responda lo mismo no importa dónde se pregunte (en qué zona), y que las bases de datos interactuen de forma apropiada para responder las preguntas. Hay dos tipos de respuestas, autoritativas y no autoritativas (el dato pertenece al que le preguntamos o no, lo tiene que pedir a otro). En definitiva es una base de datos distribuida.

Lo que en una DB se llama registro, acá se llama registro de recurso. Hay varios tipos. Ej de un tipo de registro:

DOMAIN_NAME      TTL       CLASS    TYPE     VALUE
zz.dc.uba.ar     86400     IN       A        192.168.4.1

El TTL dice por cuánto tiempo valida la información ese DNS, permite cachear.

[Acá repasa la tabla con el 'Summary of common DNS Resource Records', ver ppts de la página. Reclamarlos si no los suben. También mencionó mucho que no se que cosa está delegada. Investigar.]

Por ejemplo, hay tipos de registros usados para tareas específicas como mail. El tipo MX es para saber quién es el responsable de manejar determinado dominio de mail (lo que viene después de la @). Ej:

UBA.AR   MX    1    dirIP

Otros tipos mencionados: TXT, SOA

En realidad no hay un DNS por zona, el mismo software puede manejar varias zonas. Aún si es así, cada zona tiene su propia DB.

Problemas: si tengo un único servidor que se encarga de guardar la información para cada autoridad de zona, y se me llega a caer ese servidor, no anda nada para ningún nombre con la raíz asociada a esa autoridad.

Entonces se determinan un DNS primario y uno o varios secundarios, para soportar este tipo de contingencias.

El primario es el que se carga "a mano", los secundarios se cargan a partir del primario.

A veces también se los llama master y slaves.

El secundario cuando levanta le pide el SOA al primario. Después de un rato determinado por el campo Refresh, le vuelve a pedir. Si el Serial del nuevo SOA es mayor al anterior, se hace una transferencia de SOA.

Cuando se acaba el expire, el secundario deja de ser un DNS de la zona.

Más allá de servir como backup, tener servidores secundarios sirve para distribuir la carga de pedidos de resolución de nombres.

DNS Notify mejora el mecanismo de manera tal que cada vez que el primario se actualiza les "avisa" a los secundarios. DNS Notify no es practicable en contextos en los que el DNS primario no tiene forma de conocer a sus secundarios.

Otra mejora es hacer transferencia incremental, es decir, sólo transmitir los cambios de la nueva versión con respecto a la anterior.

El sistema de DNS dinámico permite evitar que la carga del DNS primario se haga realmente a mano. Se puede combinar con DHCP. Mi PC bootea, DHCP me da mi IP, y posteriormente yo le doy mi IP al DNS dinámico, que actualiza los datos. Así me ahorro uno varios puestos laborales, incrementando sustancialmente la tasa de desempleo del país. El DNS dinámico es un invento de los capitalistas salvajes.

Hay otro tipo de DNS, no autoritativos para ninguna zona. Sólo responden consultas. Cualquier DNS debe poder responder preguntas sobre cualquier zona. Los DNS cachean información. Si el DNS necesita preguntar por un nombre de una zona que no le corresponde, al obtener la información se lo cachea (mientras dure le TTL del registro que se obtuvo), para mejorar la performance del sistema.

Cuando un DNS no es autoritativo de ninguna zona se lo denomina caching-only.

Existen Root Name Servers, que son los que tienen la información de las direcciones de los servidores de DNS que tienen las raíces (.com, .edu, .ar, .uk, etc.).

Resolución de nombres DNS iterativa. Ver diapositiva "Iterative DNS Name Resolution"

Cuanto más chiquito el TTL, más rápido se actualizan los cambios, pero el servidor primario va a recibir muchas más consultas. Hay que elegir el TTL como un valor de compromiso entre estos dos constraints.

Resolución de nombres DNS recursiva. Ver diapositiva "Recursive DNS Name Resolution"

Una consulta es más molesta para un servidor. En general es iterativo, salvo en las hojas. Mientras más cerca de la raíz, más jodido es usar el algoritmo recursivo.

Yo puedo consultar dado una IP cuál es su nombre? Es cuasi imposible. No sabés por dónde arrancar, ya que la base de datos distribuída está indexada por nombre. Se crea un dominio nuevo a partir de root que es arpa. Entonces, para obtener el nombre de la IP 191.27.203.8, se hace una consulta DNS para obtener la IP de 8.203.27.191.in-addr.arpa. Esta consulta devuelve la IP de un DNS que tiene un registro para hacer el mapeo y devolver el nombre (que puede no ser el original).