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.