Qual é o número máximo de IPs que um DNS pode ter um registro?

Tenho uma ideia estranha - permita que várias pessoas / organizações hospedem o mesmo aplicativo e que todos os seus nós sejam acessíveis por um único nome de domínio. Isso significa que, digamos, uma rede social realmente distribuída, onde a usabilidade não é sacrificada (ou seja, os usuários não precisam se lembrar de diferentes URLs de provedor e, quando um provedor cai, alterne para outro)

Para conseguir isso, pensei que um registro DNS com vários IPs pudesse ser usado.

Então, quantos IPs um único registro DNS A pode conter? Esta resposta diz que são cerca de 30, mas o caso de uso é diferente. Para o cenário acima, eu não me importaria se um determinado ISP armazenasse em cache apenas 30, enquanto outro ISP armazenasse em cache outros 30, e assim por diante.

Isenção de responsabilidade: Sem ofensas, mas essa é uma péssima idéia. Eu não recomendo que alguém faça isso na vida real.

Mas se você der um laboratório para um cara entediado de TI, coisas engraçadas acontecerão!

Para esta experiência, usei um servidor DNS da Microsoft em execução no Server 2012 R2. Devido às complicações de hospedar uma zona DNS no Active Directory, criei uma nova zona primária denominada testing.com que não é integrada ao AD.

Usando este script:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

Comecei a criar, sem erro, 65025 registros de host para o nome testing.testing.com., com literalmente todos os endereços IPv4 de 1.1.1.1 a 1.1.255.255.

Então, eu queria ter certeza de que conseguiria quebrar o número total de 65536 (2 ^ 16 bits) de registros A sem erro, e poderia, então suponho que provavelmente poderia ter ido até 16581375 (1.1.1.1 a 1.255 .255.255,) mas eu não queria sentar aqui e assistir esse script ser executado a noite toda.

Portanto, acho seguro dizer que não há limite prático para o número de registros A que você pode adicionar a uma zona com o mesmo nome com IPs diferentes no servidor.

Mas será que realmente funciona da perspectiva de um cliente?

Aqui está o que eu recebo do meu cliente, conforme visualizado pelo Wireshark:

(Abra a imagem em uma nova guia do navegador para obter o tamanho completo.)

Como você pode ver, quando eu uso o nslookup ou o ping do meu cliente, ele emite automaticamente duas consultas - uma UDP e uma TCP. Como você já sabe, o máximo que posso obter em um datagrama UDP é de 512 bytes; portanto, quando esse limite é excedido (como 20 a 30 endereços IP), é preciso usar o TCP. Mas mesmo com o TCP, recebo apenas um subconjunto muito pequeno de registros A para testing.testing.com. 1000 registros foram retornados por consulta TCP. A lista de registros A gira 1 corretamente com cada consulta sucessiva, exatamente como você espera que o DNS de rodízio funcione. Levaria milhões de consultas para arredondar o robin em todas elas.

Não vejo como isso o ajudará a tornar sua rede de mídia social massivamente escalável e resiliente, mas há sua resposta.

Edit: No seu comentário de acompanhamento, você pergunta por que eu acho que isso geralmente é uma má ideia.

• Digamos que eu seja um usuário comum da Internet e gostaria de me conectar ao seu serviço. Digito www.bozho.biz no meu navegador. O cliente DNS no meu computador recebe 1000 registros. Bem, azar, os 30 primeiros registros da lista não respondem, porque a lista de registros A não é atualizada, ou talvez haja uma interrupção em grande escala que afeta uma parte da Internet. Digamos que meu navegador tenha um tempo limite de 5 segundos por IP antes de seguir em frente e tentar o próximo. Então agora eu estou sentado aqui, olhando para uma ampulheta girando por 2 minutos e meio, esperando o seu site carregar. Ninguém tem tempo para isso. E suponho que meu navegador da Web ou qualquer aplicativo que eu use para acessar seu serviço tente até mais do que os primeiros 4 ou 5 endereços IP. Provavelmente não.

• Se você usou a eliminação automática e permite atualizações não validadas ou anônimas na zona DNS, na esperança de manter a lista de registros A atualizada ... imagine como isso seria inseguro! Mesmo se você projetou algum sistema em que os clientes precisavam de um certificado TLS de cliente que eles obtiveram anteriormente para atualizar a zona, um cliente comprometido em qualquer lugar do planeta iniciará uma botnet e destruirá seu serviço. O DNS tradicional é precariamente inseguro, sem o fornecimento de multidões.

• Uso e desperdício enormes de largura de banda. Se toda consulta DNS exigir 32 kilobytes ou mais de largura de banda, isso não será muito bom.

• O rodízio de DNS não substitui o balanceamento de carga adequado. Ele não oferece nenhuma maneira de se recuperar de um nó inoperante ou se tornar indisponível no meio das coisas. Você instruirá seus usuários a executar um ipconfig / flushdns se o nó ao qual eles foram conectados cair? Esse tipo de problema já foi resolvido por coisas como GSLB e Anycast.

• Etc.

Para responder à pergunta conforme foi declarado ("quantos IPs um único registro DNS A pode conter?"), A resposta é muito simples: um único Aregistro contém exatamente um endereço. No entanto, pode haver vários Aregistros para o mesmo nome.

Cada endereço IPv4 ocupa 16 bytes na resposta. Cada endereço IPv6 ocupa 28 bytes na resposta.

É altamente recomendável que você garanta que a resposta caiba em 512 bytes. Isso permitiria cerca de 25 endereços IPv4 e 14 endereços IPv6 (considerando que você também precisa de outras informações no pacote). O limite exato depende do tamanho do seu nome de domínio.

Se você tiver 25 endereços IPv4 e 14 endereços IPv6, estará contando com os clientes que solicitam endereços IPv4 e IPv6 em consultas separadas. Se o cliente solicitar os dois tipos de endereços em uma única consulta (o que é raro), será necessário diminuir o valor.

Se o tamanho da resposta exceder 512 bytes, ele ainda poderá funcionar com UDP se o cliente e o servidor oferecerem suporte ao EDNS. Sem o EDNS, o cliente receberia uma resposta truncada e precisaria tentar novamente pelo TCP. Isso aumenta a comunicação de 1 a 4 ida e volta. Pior ainda, às vezes há configurações incorretas que impedem o funcionamento do DNS sobre TCP.

Mesmo se você puder espremer mais de 14 endereços na resposta sem causar problemas na camada DNS, é improvável que seja muito útil. O tempo limite usado pelo cliente antes de desistir de um endereço e passar para o próximo geralmente é significativo.

Ter que esperar pelo tempo limite, mesmo que uma vez, pode levar a uma experiência ruim do usuário. Se o cliente tivesse que passar por 14 endereços antes de obter uma resposta, o usuário teria que esperar 13 tempos limite.

O que você está descrevendo não é uma idéia especialmente nova. Como outras respostas já abordaram, você é limitado em quantos registros A pode ter em uma resposta, mas isso não diz nada sobre quantos registros A podem existir no total.

Você pode, por exemplo, implementar um servidor DNS que responda a qualquer consulta de um registro A com um IP aleatório. Consultado várias vezes, isso resultaria em 4294967296 registros A únicos: um para cada endereço IPv4.

Como eu disse, essa não é uma idéia nova. De fato, é em parte como a Akamai funciona (e provavelmente muitas outras CDNs). O registro A que você obtém para qualquer domínio da Akamai é determinado por seus servidores DNS de magia negra. Aposto que a resposta que você recebe depende do balanceamento de carga dinâmico e de preocupações geográficas.

Por exemplo, escolhi a338.g.akamaitech.net. Se eu olhar isso no meu computador agora, que usa um servidor de nomes atribuído à DHCP da Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

E se eu perguntar ao DNS do Google?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Aposto que se você tentar, aposto que receberá uma resposta diferente. Quantos servidores de borda a Akamai possui um recurso específico? Mais de dois, aposto.

Outros o mencionaram como um detalhe, mas, do ponto de vista prático, o limite máximo é o limite de tamanho de pacote UDP de 512 bytes. Embora seja possível alternar para o TCP quando o truncamento for detectado, na prática muitos / a maioria dos clientes não o fará (e, sem dúvida, não deveriam; daria uma experiência ruim ao usuário para a maioria dos aplicativos, e eu esperaria apenas transferências de zona ou outras pesquisas de propósito especial para dar suporte ao TCP). Então, você está procurando um limite de cerca de 30 endereços para IPv4 (registros A) e um pouco menos para IPv6 (AAAA), já que eles são maiores. O comprimento do nome de domínio é reduzido e limitará ainda mais o número.

A resposta curta: cerca de 25 registros A cabem em um pacote UDP. Além disso, o DNS mudará para o TCP e não será tão rápido. Você também terá problemas com clientes que não estão usando resolvedores de DNS capazes de escolher o IP "mais próximo". Além disso, com wifi e celular, o "mais próximo" geralmente não será o servidor certo.

Resposta mais longa:

Não faça isso. Uma maneira melhor seria configurar registros CNAME individuais para cada usuário que apontar para o servidor apropriado. Digamos que você tenha dois servidores server-fe seja server-rusado para IMAP. Configure o cliente IMAP de cada pessoa com o nome do servidor USERNAME.imap.example.com em que "USERNAME" é substituído pelo nome de usuário do email. Agora você pode mover pessoas entre servidores sem precisar reconfigurar o cliente de email.

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

No entanto, se você fizer isso, RECOMENDO ALTAMENTE que você gere os registros DNS automaticamente a partir de um banco de dados de usuários. Você deseja garantir que, à medida que as contas sejam criadas e excluídas, os registros DNS também sejam criados e excluídos. Caso contrário, você vai acabar com uma bagunça e muita confusão.

Eu já vi isso em empresas com literalmente milhares de usuários e, como as coisas foram automatizadas, o mundo é muito bom.

Como outros já apontaram, é uma péssima idéia para uso no mundo real.

No mundo real, existem clientes e resolvedores não conformes que têm problemas com respostas que não cabem em um único datagrama UDP e existem firewalls que aplicam idéias específicas, mas não compatíveis com o protocolo, sobre os limites de tamanho das mensagens DNS.

E mesmo que você possa contar com sua enorme resposta em todos os casos (o que você enfaticamente não pode), há outro motivo pelo qual essa é uma péssima idéia. Quanto maior o tamanho da resposta do DNS, mais tentador é a carga útil para ataques de reflexão, porque você fornece um enorme fator de amplificação. Nesse tipo de ataque de negação de serviço, comum no DNS, uma consulta UDP é enviada para um resolvedor recursivo aberto. O endereço de origem das consultas UDP normalmente é falsificado com facilidade e o invasor define a origem da consulta como o IP do destino pretendido. Dois efeitos desejáveis ​​(para o atacante) são alcançados: primeiro - um esforço de envio relativamente pequeno da parte deles (de uma pequena consulta falsificada) resulta em uma torrente comparativamente grande de tráfego indesejado que chega ao alvo (esse é o fator de amplificação), e segundo - a fonte real do ataque está oculta do alvo; o alvo conhece apenas os endereços dos resolvedores recursivos que estão sendo usados ​​como refletores.

Ponto interessante de curiosidades históricas sobre este assunto. Nos anos 90, a AOL expandiu seus registros DNS de forma que uma consulta MX retornasse> 512 bytes. Isso violou a RFC, quebrou muitos servidores SMTP (o qmail era um popular na época) e causou muitas dores de cabeça aos administradores de sistemas. A correção exigia correção ou adição de rotas estáticas.

Não sei qual é a situação atual, mas alguns anos atrás, quando toquei o qmail pela última vez, os patches ainda estavam no lugar.

http://www.gossamer-threads.com/lists/qmail/users/30503