Resolvedor DNS vs registro NS TTL

Question

Quando um resolvedor de DNS procura um domínio/zona em busca de um servidor de nomes autoritativo, ele pega todos os 6 registros e os percorre?

Sim, um servidor de nomes recursivo adequado leva em consideração todos os servidores de nomes e tentará consultar cada vez mais tarde o mais rápido.

Um algoritmo aproximado é mais ou menos assim:

a partir de uma inicialização a frio (sem cache), tente todos eles aleatoriamente, registre a rapidez com que eles respondem (talvez seja necessário separar o caso UDP do caso TCP)
depois de algum tempo, comece a usar com mais frequência o mais rápido com base nas respostas anteriores
mas observe que você precisa ter certeza de não ficar indefinidamente com qualquer servidor de nomes; você deve tentar "de tempos em tempos" os outros também. Por que? Porque a topologia da rede pode mudar, assim como os próprios servidores de nomes. ns3pode ser o mais rápido hoje para o seu ponto de vista específico, mas talvez amanhã seja ns5; então você tem que usar o mais rápido, mas nem sempre, apenas para ter certeza de poder descobrir automaticamente qualquer outro mais rápido do que aquele que você acredita ser o mais rápido no momento.

Se um resolvedor usar o primeiro servidor NS

Pare aqui. Os registros vêm em um conjunto, não em uma lista. Ou seja, não há ordem inerente no DNS. É claro que há uma ordem na representação do fio ou do display, mas ela não vem do protocolo.

Conjuntos de registros são sacolas: você recebe registros, sem pedidos. Na verdade, você pode ver que muitos servidores de nomes, para exatamente a mesma consulta, se houver vários registros na resposta, ordenarão os registros de maneira diferente cada vez que você fizer a consulta, exatamente para combater sistemas clientes que levariam em conta apenas o primeiro item e desconsidere os outros.

quando esse servidor de nomes oficial não está respondendo

Veja o algoritmo acima: se um dos servidores de nomes do NSconjunto não estiver respondendo, você pode considerar que é o mesmo que "responder como o mais lento de qualquer outro". O DNS do cliente tem tempos limite, portanto não esperará infinitamente, mas marcará que este servidor de nomes específico é muito lento e mudará para outros. Então na primeira vez você incorre em uma penalidade porque o sistema tem que tentar entrar em contato com aquele servidor de nomes, esperar um pouco (alguns segundos), tentar novamente e em algum momento parar de usar aquele servidor de nomes. Após essa rampa, ele usará os outros servidores de nomes e as coisas serão rápidas. Mas a primeira vez que você descobrir que um determinado servidor de nomes está lento/não responde ao realmente tentar contatá-lo, você não pode inferir o problema sem tentar.

Isso significa que preciso definir um TTL curto para registros NS?

Talvez, mas é principalmente irrelevante. Por que? Porque seus NSregistros são publicados na zona pai do seu domínio, para garantir a delegação DNS. Eles são publicados lá com um TTL, é claro, pois todos os registros têm um TTL anexado a eles, mas são publicados em uma zona que você não controla, portanto você NÃO pode escolher seus valores de TTL!

(Há uma discussão complicada/não completamente concluída aqui sobre esses registros, como NSse existissem em duas partes: o pai e o filho, com a pergunta "qual deles é realmente confiável"? Se o pai tiver um TTL de 1 semana nos NSregistros e você na sua zona os mesmos NSregistros têm um TTL de 1 segundo, o que o servidor de nomes recursivo deve fazer. Pode-se chegar à conclusão de que normalmente a parte filha da delegação É autoritativa, então 1 segundo vence aqui na prática; são "centrados nos pais", ou seja, eles usam os dados do lado dos pais, então 1 semana ganha lá)

TTLs são sempre uma compensação. Uma vez conhecidas, algumas pessoas chegam imediatamente à conclusão de que as coisas funcionam melhor com TTLs muito baixos... o que é verdade para alguns casos e nem tanto para outros. Os caches são bons, se eles não estivessem lá (também conhecido como: não usar TTLs grandes o suficiente), você não seria resiliente contra pequenos problemas, isso faria com que tudo desaparecesse porque os nomes dos caches já teriam expirado.

Além disso, o valor TTL não tem (ou tem pouco) impacto para o algoritmo acima ao percorrer todos os servidores de nomes, tentando com tempo limite e convergindo para o mais rápido.

Portanto, se você observar o que acontece nos servidores de nomes de TLD (que hospedam NSregistros para todos os domínios desse TLD) ou em várias recomendações, verá frequentemente NSregistros com um TTL de 1 ou 2 dias.

Algum conselho sobre como o resolvedor DNS funciona com NS não responsivo e seu TTL?

Cada resolvedor faz o seu próprio :-) Isso não é realmente especificado pelo protocolo, é um detalhe de implementação. Você pode estudar o código-fonte daquele que pode instalar, mas provavelmente não será capaz de coletar detalhes sobre isso de grandes provedores públicos de DNS recursivo.

Você pode encontrar mais detalhes aqui:

RFC 1034 §5.3.3 também fornece algumas informações (observe também que leva em consideração um caso que você esqueceu: um determinado servidor de nomes pode ter vários endereços IP - hoje mesmo deveria ser sempre o caso, com um IPv4 e um IPv6 - e não há garantia de que você obterá resultados no mesmo período de tempo com cada um):

Além dos nomes e endereços dos servidores, a estrutura de dados SLIST pode ser classificada para usar primeiro os melhores servidores e garantir que todos os endereços de todos os servidores sejam usados de maneira round-robin. A classificação pode ser uma simples função de preferência de endereços na rede local em detrimento de outros, ou pode envolver estatísticas de eventos passados, como tempos de resposta anteriores e médias de acertos.

A etapa 3 envia consultas até que uma resposta seja recebida. A estratégia é percorrer todos os endereços de todos os servidores com um tempo limite entre cada transmissão. Na prática, é importante usar todos os endereços de um host multihomed, e uma política de retransmissão muito agressiva na verdade retarda a resposta quando usada por vários resolvedores que competem pelo mesmo servidor de nomes e até mesmo ocasionalmente por um único resolvedor. SLIST normalmente contém valores de dados para controlar os tempos limite e acompanhar as transmissões anteriores.

RFC 1035 §7.2 tem isto a dizer:

Para completar a inicialização do SLIST, o resolvedor anexa todas as informações de histórico que possui a cada endereço no SLIST. Isso geralmente consistirá em algum tipo de média ponderada para o tempo de resposta do endereço e a média de acertos do endereço (ou seja, com que frequência o endereço respondeu à solicitação). Observe que essas informações devem ser mantidas por endereço, e não por servidor de nomes, porque o tempo de resposta e a média de acertos de um servidor específico podem variar consideravelmente de endereço para endereço. Observe também que essas informações são, na verdade, específicas para um par endereço do resolvedor/endereço do servidor, portanto, um resolvedor com vários endereços pode querer manter históricos separados para cada um de seus endereços. Parte desta etapa deve lidar com endereços que não possuem esse histórico; neste caso, um tempo de ida e volta esperado de 5 a 10 segundos deve ser o pior caso, com estimativas mais baixas para a mesma rede local, etc.

Observe que sempre que uma delegação é seguida, o algoritmo do resolvedor reinicializa SLIST.

As informações estabelecem uma classificação parcial dos endereços de servidores de nomes disponíveis. Cada vez que um endereço é escolhido, o estado deve ser alterado para evitar sua seleção novamente até que todos os outros endereços tenham sido tentados. O tempo limite para cada transmissão deve ser 50-100% maior que o valor médio previsto para permitir variação na resposta.

Também para finalizar e mais especificamente sobre isso:

Conforme ilustrado neste artigo da imperva

Este artigo mencionado fala sobre o problema que aconteceu com pessoas que usavam servidores de nomes Dyn, quando houve uma interrupção. Então, sim, se você usar apenas servidores de nomes Dyn, terá um problema. Mesmo que você mude sua zona para usar outras, o NSTTL dos registros significa que sua mudança não será vista imediatamente. Mas isso, na realidade, não diz muito sobre TTLs, mas apenas diz muito sobre o gerenciamento de DNS: se você quiser ser resiliente, para zonas importantes, não use um único provedor de DNS, mas vários (o que, claro, exige alguma coordenação entre Com eles, você não pode simplesmente misturar e combinar arbitrariamente os provedores X e Y, e é ainda mais complicado se você incluir o DNSSEC na mistura, mas é possível). Dessa forma, exatamente por causa do algoritmo rapidamente elaborado acima, mesmo que 2 em cada 5 digamos que o servidor de nomes não esteja respondendo completamente porque este provedor específico está com um problema, o outro assumirá a carga e fará seu domínio funcionar. Pode haver um atraso extra em cada nova consulta para os visitantes (porque todos os servidores de nomes recursivos não conseguem entender imediatamente que precisam mudar para servidores de nomes específicos porque 2 em cada 5 estão inativos) e também mais atrasos porque os outros 3 estão sobrecarregados com mais consultas do que o normal (o DNS é balanceador de carga por padrão, então, em teoria, cada servidor de nomes recebe aproximadamente o mesmo volume de consultas), mas ainda assim uma resposta será dada.

PS: não solicitado, mas como às vezes não fica claro, todos os registros em um determinado conjunto de registros devem ter o mesmo TTL. O TTL é por registro, mas precisa ser o mesmo em um determinado conjunto de registros, o que significa para uma determinada tupla de (nome, tipo de registro) [e classe, mas ninguém usa nada além INde classe]

Answer 1

Quando um resolvedor de DNS procura um domínio/zona em busca de um servidor de nomes autoritativo, ele pega todos os 6 registros e os percorre?

Sim, um servidor de nomes recursivo adequado leva em consideração todos os servidores de nomes e tentará consultar cada vez mais tarde o mais rápido.

Um algoritmo aproximado é mais ou menos assim:

a partir de uma inicialização a frio (sem cache), tente todos eles aleatoriamente, registre a rapidez com que eles respondem (talvez seja necessário separar o caso UDP do caso TCP)
depois de algum tempo, comece a usar com mais frequência o mais rápido com base nas respostas anteriores
mas observe que você precisa ter certeza de não ficar indefinidamente com qualquer servidor de nomes; você deve tentar "de tempos em tempos" os outros também. Por que? Porque a topologia da rede pode mudar, assim como os próprios servidores de nomes. ns3pode ser o mais rápido hoje para o seu ponto de vista específico, mas talvez amanhã seja ns5; então você tem que usar o mais rápido, mas nem sempre, apenas para ter certeza de poder descobrir automaticamente qualquer outro mais rápido do que aquele que você acredita ser o mais rápido no momento.

Se um resolvedor usar o primeiro servidor NS

Pare aqui. Os registros vêm em um conjunto, não em uma lista. Ou seja, não há ordem inerente no DNS. É claro que há uma ordem na representação do fio ou do display, mas ela não vem do protocolo.

Conjuntos de registros são sacolas: você recebe registros, sem pedidos. Na verdade, você pode ver que muitos servidores de nomes, para exatamente a mesma consulta, se houver vários registros na resposta, ordenarão os registros de maneira diferente cada vez que você fizer a consulta, exatamente para combater sistemas clientes que levariam em conta apenas o primeiro item e desconsidere os outros.

quando esse servidor de nomes oficial não está respondendo

Veja o algoritmo acima: se um dos servidores de nomes do NSconjunto não estiver respondendo, você pode considerar que é o mesmo que "responder como o mais lento de qualquer outro". O DNS do cliente tem tempos limite, portanto não esperará infinitamente, mas marcará que este servidor de nomes específico é muito lento e mudará para outros. Então na primeira vez você incorre em uma penalidade porque o sistema tem que tentar entrar em contato com aquele servidor de nomes, esperar um pouco (alguns segundos), tentar novamente e em algum momento parar de usar aquele servidor de nomes. Após essa rampa, ele usará os outros servidores de nomes e as coisas serão rápidas. Mas a primeira vez que você descobrir que um determinado servidor de nomes está lento/não responde ao realmente tentar contatá-lo, você não pode inferir o problema sem tentar.

Isso significa que preciso definir um TTL curto para registros NS?

Talvez, mas é principalmente irrelevante. Por que? Porque seus NSregistros são publicados na zona pai do seu domínio, para garantir a delegação DNS. Eles são publicados lá com um TTL, é claro, pois todos os registros têm um TTL anexado a eles, mas são publicados em uma zona que você não controla, portanto você NÃO pode escolher seus valores de TTL!

(Há uma discussão complicada/não completamente concluída aqui sobre esses registros, como NSse existissem em duas partes: o pai e o filho, com a pergunta "qual deles é realmente confiável"? Se o pai tiver um TTL de 1 semana nos NSregistros e você na sua zona os mesmos NSregistros têm um TTL de 1 segundo, o que o servidor de nomes recursivo deve fazer. Pode-se chegar à conclusão de que normalmente a parte filha da delegação É autoritativa, então 1 segundo vence aqui na prática; são "centrados nos pais", ou seja, eles usam os dados do lado dos pais, então 1 semana ganha lá)

TTLs são sempre uma compensação. Uma vez conhecidas, algumas pessoas chegam imediatamente à conclusão de que as coisas funcionam melhor com TTLs muito baixos... o que é verdade para alguns casos e nem tanto para outros. Os caches são bons, se eles não estivessem lá (também conhecido como: não usar TTLs grandes o suficiente), você não seria resiliente contra pequenos problemas, isso faria com que tudo desaparecesse porque os nomes dos caches já teriam expirado.

Além disso, o valor TTL não tem (ou tem pouco) impacto para o algoritmo acima ao percorrer todos os servidores de nomes, tentando com tempo limite e convergindo para o mais rápido.

Portanto, se você observar o que acontece nos servidores de nomes de TLD (que hospedam NSregistros para todos os domínios desse TLD) ou em várias recomendações, verá frequentemente NSregistros com um TTL de 1 ou 2 dias.

Algum conselho sobre como o resolvedor DNS funciona com NS não responsivo e seu TTL?

Cada resolvedor faz o seu próprio :-) Isso não é realmente especificado pelo protocolo, é um detalhe de implementação. Você pode estudar o código-fonte daquele que pode instalar, mas provavelmente não será capaz de coletar detalhes sobre isso de grandes provedores públicos de DNS recursivo.

Você pode encontrar mais detalhes aqui:

RFC 1034 §5.3.3 também fornece algumas informações (observe também que leva em consideração um caso que você esqueceu: um determinado servidor de nomes pode ter vários endereços IP - hoje mesmo deveria ser sempre o caso, com um IPv4 e um IPv6 - e não há garantia de que você obterá resultados no mesmo período de tempo com cada um):

Além dos nomes e endereços dos servidores, a estrutura de dados SLIST pode ser classificada para usar primeiro os melhores servidores e garantir que todos os endereços de todos os servidores sejam usados de maneira round-robin. A classificação pode ser uma simples função de preferência de endereços na rede local em detrimento de outros, ou pode envolver estatísticas de eventos passados, como tempos de resposta anteriores e médias de acertos.

A etapa 3 envia consultas até que uma resposta seja recebida. A estratégia é percorrer todos os endereços de todos os servidores com um tempo limite entre cada transmissão. Na prática, é importante usar todos os endereços de um host multihomed, e uma política de retransmissão muito agressiva na verdade retarda a resposta quando usada por vários resolvedores que competem pelo mesmo servidor de nomes e até mesmo ocasionalmente por um único resolvedor. SLIST normalmente contém valores de dados para controlar os tempos limite e acompanhar as transmissões anteriores.

RFC 1035 §7.2 tem isto a dizer:

Para completar a inicialização do SLIST, o resolvedor anexa todas as informações de histórico que possui a cada endereço no SLIST. Isso geralmente consistirá em algum tipo de média ponderada para o tempo de resposta do endereço e a média de acertos do endereço (ou seja, com que frequência o endereço respondeu à solicitação). Observe que essas informações devem ser mantidas por endereço, e não por servidor de nomes, porque o tempo de resposta e a média de acertos de um servidor específico podem variar consideravelmente de endereço para endereço. Observe também que essas informações são, na verdade, específicas para um par endereço do resolvedor/endereço do servidor, portanto, um resolvedor com vários endereços pode querer manter históricos separados para cada um de seus endereços. Parte desta etapa deve lidar com endereços que não possuem esse histórico; neste caso, um tempo de ida e volta esperado de 5 a 10 segundos deve ser o pior caso, com estimativas mais baixas para a mesma rede local, etc.

Observe que sempre que uma delegação é seguida, o algoritmo do resolvedor reinicializa SLIST.

As informações estabelecem uma classificação parcial dos endereços de servidores de nomes disponíveis. Cada vez que um endereço é escolhido, o estado deve ser alterado para evitar sua seleção novamente até que todos os outros endereços tenham sido tentados. O tempo limite para cada transmissão deve ser 50-100% maior que o valor médio previsto para permitir variação na resposta.

Também para finalizar e mais especificamente sobre isso:

Conforme ilustrado neste artigo da imperva

Este artigo mencionado fala sobre o problema que aconteceu com pessoas que usavam servidores de nomes Dyn, quando houve uma interrupção. Então, sim, se você usar apenas servidores de nomes Dyn, terá um problema. Mesmo que você mude sua zona para usar outras, o NSTTL dos registros significa que sua mudança não será vista imediatamente. Mas isso, na realidade, não diz muito sobre TTLs, mas apenas diz muito sobre o gerenciamento de DNS: se você quiser ser resiliente, para zonas importantes, não use um único provedor de DNS, mas vários (o que, claro, exige alguma coordenação entre Com eles, você não pode simplesmente misturar e combinar arbitrariamente os provedores X e Y, e é ainda mais complicado se você incluir o DNSSEC na mistura, mas é possível). Dessa forma, exatamente por causa do algoritmo rapidamente elaborado acima, mesmo que 2 em cada 5 digamos que o servidor de nomes não esteja respondendo completamente porque este provedor específico está com um problema, o outro assumirá a carga e fará seu domínio funcionar. Pode haver um atraso extra em cada nova consulta para os visitantes (porque todos os servidores de nomes recursivos não conseguem entender imediatamente que precisam mudar para servidores de nomes específicos porque 2 em cada 5 estão inativos) e também mais atrasos porque os outros 3 estão sobrecarregados com mais consultas do que o normal (o DNS é balanceador de carga por padrão, então, em teoria, cada servidor de nomes recebe aproximadamente o mesmo volume de consultas), mas ainda assim uma resposta será dada.

PS: não solicitado, mas como às vezes não fica claro, todos os registros em um determinado conjunto de registros devem ter o mesmo TTL. O TTL é por registro, mas precisa ser o mesmo em um determinado conjunto de registros, o que significa para uma determinada tupla de (nome, tipo de registro) [e classe, mas ninguém usa nada além INde classe]

Resolvedor DNS vs registro NS TTL

Responder1

informação relacionada