Por que o DNS funciona da maneira que funciona?

Esta é uma pergunta canônica sobre DNS (Domain Name Service).

Se meu entendimento do sistema DNS estiver correto, o registro .com manterá uma tabela que mapeia domínios (www.example.com) para servidores DNS.

1. Qual a vantagem? Por que não mapear diretamente para um endereço IP?

2. Se o único registro que precisa ser alterado quando estou configurando um servidor DNS para apontar para um endereço IP diferente, está localizado no servidor DNS, por que o processo não é instantâneo?

3. Se o único motivo do atraso são os caches de DNS, é possível ignorá-los, para que eu possa ver o que está acontecendo em tempo real?

Na verdade, é mais complicado do que isso - em vez de um "registro central (que) mantém uma tabela que mapeia domínios (www.mysite.com) para servidores DNS", existem várias camadas de hierarquia

Há um registro central (os servidores raiz) que contêm apenas um pequeno conjunto de entradas: os (servidor de nomes) NS registros para todos os domínios de nível superior - .com, .net, .org, .uk, .us, .au, e assim por diante.

Esses servidores contêm apenas registros NS para o próximo nível abaixo. Para pegar um exemplo, os servidores de nomes para o .ukdomínio só tem entradas para .co.uk, .ac.uke as outras zonas segundo nível em uso no Reino Unido.

Esses servidores contêm apenas registros NS para o próximo nível abaixo - para continuar o exemplo, eles informam onde encontrar os registros NS google.co.uk. É nesses servidores que você finalmente encontrará um mapeamento entre um nome de host www.google.co.uke um endereço IP.

Como uma ruga extra, cada camada também servirá para registros de 'cola'. Cada registro NS mapeia um domínio para um nome de host - por exemplo, os registros NS para a .uklista nsa.nic.ukcomo um dos servidores. Para chegar ao próximo nível, precisamos descobrir os registros NS de nic.ukare e eles também incluem nsa.nic.uk. Então agora precisamos saber o IP de nsa.nic.uk, mas para descobrir isso, precisamos fazer uma consulta para nsa.nic.uk, mas não podemos fazer essa consulta até conhecermos o IP para nsa.nic.uk...

Para resolver esse dilema, os servidores para .ukadicionar o registro A nsa.nic.ukna ADDITIONAL SECTIONresposta (resposta abaixo aparada por questões de brevidade):

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

Sem esses registros de cola extra, nunca poderíamos encontrar os servidores de nomes nic.uk.e, portanto, nunca poderíamos procurar nenhum domínio hospedado lá.

Para voltar às suas perguntas ...

a) Qual é a vantagem? Por que não mapear diretamente para um endereço IP?

Por um lado, ele permite que as edições de cada zona individual sejam distribuídas. Se você deseja atualizar a entrada www.mydomain.co.uk, basta editar as informações no mydomain.co.ukservidor de nomes do seu. Não há necessidade de notificar os .co.ukservidores centrais , nem os .ukservidores nem os servidores de nomes raiz. Se houvesse apenas um único registro central que mapeasse todos os níveis até a hierarquia que tivesse que ser notificado sobre todas as alterações de uma entrada DNS por toda a cadeia, seria absolutamente inundado de tráfego.

Antes de 1982, era assim que a resolução de nomes acontecia. Um registro central foi notificado sobre todas as atualizações e eles distribuíram um arquivo chamado hosts.txtque continha o nome do host e o endereço IP de todas as máquinas da Internet. Uma nova versão desse arquivo era publicada a cada poucas semanas, e todas as máquinas da Internet precisavam baixar uma nova cópia. Bem antes de 1982, isso estava começando a se tornar problemático e, portanto, o DNS foi inventado para fornecer um sistema mais distribuído.

Por outro lado, esse seria um ponto único de falha - se o registro central único fosse desativado, a Internet inteira ficaria offline. Ter um sistema distribuído significa que as falhas afetam apenas pequenas seções da Internet, não a coisa toda.

(Para fornecer redundância extra, na verdade existem 13 clusters de servidores separados que atendem à zona raiz. Quaisquer alterações nos registros de domínio de nível superior precisam ser enviadas para todas as 13; imagine ter que coordenar a atualização de todas as 13 para cada alteração única para qualquer nome de host em qualquer lugar do mundo ...)

b) Se o único registro que precisa ser alterado quando estou configurando um servidor DNS para apontar para um endereço IP diferente está localizado no servidor DNS, por que o processo não é instantâneo?

Porque o DNS utiliza muito cache para acelerar as coisas e diminuir a carga nos NSes. Sem o armazenamento em cache, toda vez que você visitou google.co.ukseu computador, teria que sair para a rede para procurar os servidores .uk, então .co.uk, então .google.co.uk, então www.google.co.uk. Na verdade, essas respostas não mudam muito; portanto, procurá-las sempre é uma perda de tempo e tráfego de rede. Em vez disso, quando o NS retornar registros para o seu computador, ele incluirá um valor TTL, que informa ao computador para armazenar em cache os resultados por alguns segundos.

Por exemplo, os registros NS para .ukum TTL de 172800 segundos - 2 dias. O Google é ainda mais conservador - os registros NS google.co.uktêm um TTL de 4 dias. Os serviços que contam com a capacidade de atualizar rapidamente podem escolher um TTL muito menor - por exemplo, telegraph.co.ukpossui um TTL de apenas 600 segundos em seus registros NS.

Se você deseja que as atualizações na sua zona sejam quase instantâneas, você pode diminuir o TTL o quanto quiser. Quanto menor a configuração, mais tráfego os servidores verão, pois os clientes atualizam seus registros com mais frequência. Toda vez que um cliente precisar entrar em contato com seus servidores para fazer uma consulta, isso causará algum atraso, pois é mais lento do que procurar a resposta no cache local, portanto, você também deve considerar a troca entre atualizações rápidas e um serviço rápido.

c) Se a única razão para o atraso são os caches de DNS, é possível ignorá-los, para que eu possa ver o que está acontecendo em tempo real?

Sim, isso é fácil se você estiver testando manualmente com digferramentas semelhantes - basta informar qual servidor entrar em contato.

Aqui está um exemplo de uma resposta em cache:

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

A seção de sinalizadores aqui não contém o aasinalizador, portanto, podemos ver que esse resultado veio de um cache e não diretamente de uma fonte autorizada. De fato, podemos ver que ele veio 97.107.133.4, o que é um dos resolvedores de DNS locais da Linode. O fato de a resposta ter sido fornecida em um cache muito próximo a mim significa que foram necessários 0 ms para obter uma resposta; mas, como veremos em breve, o preço pago por essa velocidade é que a resposta está quase cinco minutos desatualizada.

Para ignorar o resolvedor do Linode e ir direto à fonte, basta escolher um desses NSes e dizer ao dig para contatá-lo diretamente:

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

Você pode ver que, desta vez, os resultados foram exibidos diretamente da fonte - observe a aasinalização, que indica que os resultados vieram de uma fonte autorizada. No meu exemplo anterior, os resultados vieram do meu cache local e, portanto, não possuem o aasinalizador. Percebo que a fonte autorizada desse domínio define um TTL de 600 segundos. Os resultados que obtive anteriormente de um cache local tinham um TTL de apenas 319 segundos, o que me indica que eles estavam no cache por (600-319) segundos - quase 5 minutos - antes de eu os ver.

Embora o TTL aqui seja de apenas 600 segundos, alguns ISPs tentarão reduzir seu tráfego ainda mais, forçando seus resolvedores de DNS a armazenar em cache os resultados por mais tempo - em alguns casos, por 24 horas ou mais. É tradicional (de uma maneira que não sabemos se é realmente necessário, mas vamos ser seguros) assumir que qualquer alteração no DNS que você fizer não será visível em todos os lugares do site. Internet por 24 a 48 horas.

a) O número de mapeamentos de IP -> host no mundo é REALMENTE grande. Este sistema distribui a responsabilidade de hospedar todos os registros MX e subdomínio e todos os outros registros DNS para o proprietário do nome de domínio. Esse era basicamente o objetivo do nome de domínio. .comé realizada por um registro, onde .ukpode ser realizada por outro. Da mesma forma example.come otherexample.compode ser hospedado separadamente, para que os recursos possam ser distribuídos.

b) É armazenado em cache, o que reduz o número de ocorrências no host DNS para uma pequena fração do que seria de outra forma. Por padrão, os registros permanecem 2 dias no cache antes de serem descartados. Isso pode ser alterado alterando o TTL (tempo de vida) do registro.

c) Você pode efetivamente impedir que os registros sejam armazenados em cache definindo um TTL muito curto. Isso NÃO é recomendado, a menos que você o esteja usando para DNS dinâmico. O armazenamento em cache reduz muito os acessos no servidor DNS. Para escolher um número adivinhado, estamos falando em cancelar 95% dos pedidos.

Se você estiver em um sistema * nix, faça o download de uma cópia dos djbdns de Dan Bernstein em http://cr.yp.to/djbdns.html e execute o programa dnstrace para ver como o sistema de consultas recursivas funciona. É muito informativo.

a) O número de possíveis nomes de domínio é muito grande para um servidor manipular. E não há apenas .com; há .net, .org, .se, .info e muitos outros. Adicione a isso, você pode delegar a responsabilidade por um subdomínio (que é efetivamente o que comfaz). O DNS menos centralizado facilita o gerenciamento.

b) Máquinas ao longo do caminho do usuário para você ter caches DNS, a fim de minimizar o número de solicitações necessárias. Evita, por exemplo, enviar spam à rede com solicitações para o endereço "serverfault.com" toda vez que você obtém uma página do SF. Esses servidores podem até armazenar em cache os resultados "o domínio não existe", e é por isso que pode demorar um pouco até que um novo domínio seja exibido.

c) Embora você possa desativar o cache, geralmente existem outros servidores DNS entre sua máquina e o servidor DNS do seu domínio.com. O servidor DNS do seu ISP, por exemplo, tentará armazenar em cache o máximo possível. Os únicos registros que são atualizados com relativa rapidez pela rede são aqueles com um TTL curto (que basicamente diz "eu sou válido apenas por alguns segundos; depois disso, solicite novamente as informações atuais"). O motivo pelo qual os TTLs são tão altos é que o servidor responsável pelo domínio pode descarregar parte do trabalho para outros servidores. Se você tivesse toda a rede entrando em contato com um ou dois servidores DNS rinky-dink para cada acesso ao seu site, eles seriam praticamente inutilizáveis ​​no segundo em que alguém visse seu site em /., Digg etc.