¿Por qué DNS funciona de la misma manera?

Esta es una pregunta canónica sobre DNS (Servicio de nombres de dominio).

Si mi comprensión del sistema DNS es correcta, el registro .com contiene una tabla que asigna dominios (www.example.com) a los servidores DNS.

1. Cual es la ventaja? ¿Por qué no asignar directamente a una dirección IP?

2. Si el único registro que necesita cambiar cuando estoy configurando un servidor DNS para que apunte a una dirección IP diferente, se encuentra en el servidor DNS, ¿por qué el proceso no es instantáneo?

3. Si la única razón de la demora son las memorias caché de DNS, ¿es posible omitirlas para poder ver lo que sucede en tiempo real?

En realidad, es más complicado que eso: en lugar de un "registro central (que) contiene una tabla que asigna dominios (www.mysite.com) a servidores DNS", hay varias capas de jerarquía

Hay un registro central (los servidores raíz) que contienen sólo un pequeño conjunto de entradas: los servidores de nombres (NS) registros para todos los dominios de nivel superior - .com, .net, .org, .uk, .us, .au, y así sucesivamente.

Esos servidores solo contienen registros NS para el siguiente nivel inferior. Para recoger un ejemplo, los servidores de nombres para el .ukdominio acaba de entradas para .co.uk, .ac.uky las otras zonas de segundo nivel en uso en el Reino Unido.

Esos servidores solo contienen registros NS para el siguiente nivel inferior: para continuar con el ejemplo, le indican dónde encontrar los registros NS google.co.uk. Es en esos servidores donde finalmente encontrará una asignación entre un nombre de host como www.google.co.uky una dirección IP.

Como una arruga adicional, cada capa también servirá registros de "pegamento". Cada registro NS asigna un dominio a un nombre de host; por ejemplo, los registros NS para la .uklista nsa.nic.ukcomo uno de los servidores. Para llegar al siguiente nivel, necesitamos encontrar los registros NS para nic.ukare, y resultan incluir nsa.nic.uktambién. Así que ahora necesitamos saber la IP de nsa.nic.uk, pero para descubrirlo necesitamos hacer una consulta nsa.nic.uk, pero no podemos hacer esa consulta hasta que sepamos la IP para nsa.nic.uk...

Para resolver este dilema, los servidores para .ukagregar el registro A nsa.nic.uka ADDITIONAL SECTIONla respuesta (la respuesta a continuación se recorta por brevedad):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Sin estos registros de pegamento adicionales, nunca podríamos encontrar los servidores de nombres nic.uk.y, por lo tanto, nunca podríamos buscar ningún dominio alojado allí.

Para volver a sus preguntas ...

a) ¿Cuál es la ventaja? ¿Por qué no asignar directamente a una dirección IP?

Por un lado, permite distribuir ediciones a cada zona individual. Si desea actualizar la entrada www.mydomain.co.uk, solo necesita editar la información en su mydomain.co.ukservidor de nombres. No es necesario notificar a los .co.ukservidores centrales , ni a los .ukservidores, ni a los servidores de nombres raíz. Si solo hubiera un único registro central que mapeara todos los niveles en toda la jerarquía que tenía que ser notificado sobre cada cambio de una entrada de DNS en toda la cadena, estaría absolutamente inundado de tráfico.

Antes de 1982, así fue como ocurrió la resolución de nombres. Se notificó a un registro central sobre todas las actualizaciones, y distribuyeron un archivo llamado hosts.txtque contenía el nombre de host y la dirección IP de cada máquina en Internet. Se publicaba una nueva versión de este archivo cada pocas semanas, y cada máquina en Internet tendría que descargar una nueva copia. Mucho antes de 1982, esto comenzaba a ser problemático, por lo que se inventó el DNS para proporcionar un sistema más distribuido.

Por otro lado, esto sería un Punto Único de Falla: si el registro central único cayera, todo el Internet estaría fuera de línea. Tener un sistema distribuido significa que las fallas solo afectan a pequeñas secciones de Internet, no a todo.

(Para proporcionar redundancia adicional, en realidad hay 13 grupos separados de servidores que sirven a la zona raíz. Cualquier cambio en los registros de dominio de nivel superior debe enviarse a los 13; imagine tener que coordinar la actualización de los 13 para cada cambio a cualquier nombre de host en cualquier parte del mundo ...)

b) Si el único registro que necesita cambiar cuando estoy configurando un servidor DNS para que apunte a una dirección IP diferente se encuentra en el servidor DNS, ¿por qué el proceso no es instantáneo?

Debido a que DNS utiliza una gran cantidad de almacenamiento en caché para acelerar las cosas y disminuir la carga en los NSes. Sin almacenamiento en caché, cada vez que visitaba google.co.uksu computadora tendría que salir a la red para buscar los servidores .uk, luego .co.uk, luego .google.co.uk, luego www.google.co.uk. Esas respuestas en realidad no cambian mucho, por lo que buscarlas cada vez es una pérdida de tiempo y tráfico de red. En cambio, cuando el NS devuelve registros a su computadora, incluirá un valor TTL, que le indica a su computadora que guarde en caché los resultados durante varios segundos.

Por ejemplo, los registros NS .uktienen un TTL de 172800 segundos - 2 días. Google es aún más conservador: los registros NS google.co.uktienen un TTL de 4 días. Los servicios que dependen de poder actualizar rápidamente pueden elegir un TTL mucho más bajo; por ejemplo, telegraph.co.uktiene un TTL de solo 600 segundos en sus registros NS.

Si desea que las actualizaciones de su zona sean casi instantáneas, puede optar por reducir su TTL lo más que pueda. Cuanto menor sea su configuración, más tráfico verán sus servidores, ya que los clientes actualizan sus registros con más frecuencia. Cada vez que un cliente tiene que ponerse en contacto con sus servidores para realizar una consulta, esto causará cierto retraso, ya que es más lento que buscar la respuesta en su caché local, por lo que también querrá considerar la compensación entre actualizaciones rápidas y un servicio rápido.

c) Si la única razón de la demora son las memorias caché de DNS, ¿es posible omitirlas para que pueda ver lo que sucede en tiempo real?

Sí, esto es fácil si está probando manualmente digo con herramientas similares, solo dígale con qué servidor contactar.

Aquí hay un ejemplo de una respuesta en caché:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

La sección de banderas aquí no contiene la aabandera, por lo que podemos ver que este resultado provino de un caché en lugar de directamente de una fuente autorizada. De hecho, podemos ver que proviene 97.107.133.4, que resulta ser uno de los solucionadores de DNS locales de Linode. El hecho de que la respuesta se sirviera de un caché muy cerca de mí significa que me tomó 0 ms para obtener una respuesta; pero como veremos en un momento, el precio que pago por esa velocidad es que la respuesta está casi 5 minutos desactualizada.

Para omitir el resolutor de Linode e ir directamente a la fuente, simplemente elija uno de esos NS y dígale a dig para contactarlo directamente:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

Puede ver que esta vez, los resultados se entregaron directamente desde la fuente: observe la aabandera, que indica que los resultados provienen de una fuente autorizada. En mi ejemplo anterior, los resultados provienen de mi caché local, por lo que carecen de la aabandera. Puedo ver que la fuente autorizada para este dominio establece un TTL de 600 segundos. Los resultados que obtuve antes de un caché local tenían un TTL de solo 319 segundos, lo que me dice que habían estado en el caché durante (600-319) segundos, casi 5 minutos, antes de que los viera.

Aunque el TTL aquí es de solo 600 segundos, algunos ISP intentarán reducir aún más su tráfico al obligar a sus solucionadores de DNS a almacenar en caché los resultados durante más tiempo, en algunos casos, durante 24 horas o más. Es tradicional (de una manera que no sabemos si esto es realmente necesario, pero seamos seguros) asumir que cualquier cambio de DNS que realice no será visible en todas partes en el Internet por 24-48 horas.

a) El número de IP -> asignaciones de nombres de host en el mundo es REALMENTE grande. Este sistema distribuye la responsabilidad de alojar todos los registros de subdominio y MX y cualquier otro registro DNS al propietario del nombre de dominio. Este era más o menos el punto del nombre de dominio. .comestá en manos de un registro donde .ukpuede estar en manos de otro De la misma manera example.comy otherexample.comse pueden alojar por separado por lo que los recursos pueden ser distribuidos.

b) Se almacena en caché, lo que reduce la cantidad de visitas en su host DNS a una pequeña fracción de lo que sería de otra manera. Por defecto, los registros viven 2 días en el caché antes de ser descartados. Esto se puede cambiar alterando el TTL (tiempo de vida) del registro.

c) Puede detener efectivamente los registros que se almacenan en caché configurando un TTL realmente corto. Esto NO se recomienda a menos que lo esté utilizando para DNS dinámico. El almacenamiento en caché reduce mucho los éxitos en el servidor DNS. Para elegir un número adivinado del aire, estamos hablando de eliminar el 95% de las solicitudes.

Si utiliza un sistema * nix, descargue una copia de los djbdns de Dan Bernstein de http://cr.yp.to/djbdns.html y ejecute su programa dnstrace para ver cómo funciona el sistema de consulta recursiva. Es muy informativo.

a) El número de posibles nombres de dominio es demasiado grande para que lo pueda manejar un servidor. Y no solo hay .com; hay .net, .org, .se, .info y muchos otros. Además de eso, puede delegar la responsabilidad de un subdominio (que es efectivamente lo que comhace). El hecho de que DNS esté menos centralizado hace que todo sea más fácil de administrar.

b) Las máquinas en el camino desde el usuario hasta usted tienen cachés DNS para minimizar la cantidad de solicitudes necesarias. Evita, por ejemplo, enviar spam a la red con solicitudes de la dirección de "serverfault.com" cada vez que recibe una página de SF. Esos servidores pueden incluso almacenar en caché los resultados de "el dominio no existe", por lo que puede tomar un tiempo hasta que aparezca un dominio nuevo.

c) Aunque puede deshabilitar su caché, a menudo hay otros servidores DNS entre su máquina y el servidor DNS de yourdomain.com. El servidor DNS de su ISP, por ejemplo, intentará almacenar en caché tanto como sea posible. Los únicos registros que se actualizan relativamente rápido en la red son aquellos con un TTL corto (que básicamente dice "solo soy válido por unos segundos; después de eso, vuelva a preguntarme por la información actual"). Sin embargo, la razón por la cual los TTL son tan altos es para que el servidor responsable del dominio pueda descargar parte del trabajo a otros servidores. Si tuviera toda la red contactando sus uno o dos servidores DNS de rinky-dink por cada visita a su sitio web, serían prácticamente inutilizables en el momento en que alguien viera su sitio en /., Digg, etc.