Qual é a melhor prática ao criar registros que apontam para localhost? É considerado tabu ou existem alguns casos válidos onde é permitido?
Eu tenho uma dúzia de domínios onde configuro "local". subdomínios que apontam para 127.0.0.1 para ajudar no desenvolvimento local de aplicativos da Web vinculados a esses domínios. Eu e outros desenvolvedores da minha equipe costumamos trabalhar com vários sites em nossos locais, e referir-nos a IPs na URL ou manter um mapa local de domínios em seu arquivo hosts tende a causar confusão e é difícil de manter com o tempo.
Então, achei que registrá-los como subdomínios seria uma maneira rápida e fácil de fornecer atalhos para todos. E isso aconteceu. Funcionou por algumas semanas, e de repente parou de funcionar. Então eu entrei no controle de DNS do meu provedor, e com certeza, todo o "local". Um registro foi deletado.
Meu anfitrião é Godaddy.
Antes de eu ir nuclear em Godaddy para modificar meus registros de DNS sem a minha permissão, existe uma razão legítima por que eles teriam apagado eles? Eles acham que foi algum tipo de problema de segurança ou violação? Godaddy é apenas uma empresa terrível em geral, mas mudar de provedor de DNS não é uma tarefa que está no topo da minha lista. Isso é algo sobre o qual eu deveria estar legitimamente irritado?
Embora talvez um pouco estranho, eu não sei de nenhum padrão ou especificação específica que proíba fazer tal coisa no DNS público em geral. Poderia haver alguma peculiaridade da plataforma GoDaddy que causa algum tipo de problema ao usar endereços de loopback, ou talvez tenha sido removida apenas porque é 'não padrão' ou 'ímpar'.
Se as máquinas estão todas na mesma rede e não a deixam, você poderia criar esses registros em seu DNS interno?
Se eu tivesse que adivinhar, este é provavelmente um esforço equivocado para evitar a reflexão do tráfego. Tome o seguinte exemplo:
$ORIGIN example.com.
stophittingyourself IN NS ns1.stophittingyourself
ns1.stophittingyourself IN A 127.0.0.1
Se eu enviasse uma consulta para noreally.stophittingyourself.example.com. para um servidor DNS recursivo, ele seguiria a cadeia de referência e tentaria consultar 127.0.0.1:53. As probabilidades são altas de que existe, de fato, um ouvinte localhost e, na maioria dos casos, o resultado líquido é o servidor falando sozinho. Isso inevitavelmente resultaria em falha de armazenamento em cache ... mas sempre que você alterar noreally para somethingelse , essa falha deverá ser armazenada em cache separadamente por RFC.
O resultado líquido é que a referência 127.0.0.1 pode ser usada para desperdiçar recursos com mais eficiência do que apontar para um IP aleatório que não responde ou não é autoritativo. Tentar preveni-lo nessa camada é estranho , especialmente porque faz mais sentido para a vítima declarar uma lista de redes com as quais não deve se comunicar para dados autoritativos (incluindo 127.0.0.0/8), mas isso nunca impediu que um negócio fizesse coisas bobas em nome da "segurança" com aspas.
tangente semi-relacionada: se você executar um servidor DNS recursivo e nunca pensou em referências usadas para direcionar o tráfego dessa maneira, convém verificar como o seu software DNS pode ser configurado para ignorar essas referências. Embora um firewall também possa ajudar aqui, prometo que os contadores de pacotes na sua interface de loopback serão muito mais silenciosos se você lidar com o tráfego de clientes.
Exemplo baseado em BIND:
# refuse to loop back on ourself
server 203.0.113.0/24 { bogus yes; };
server 127.0.0.0/8 { bogus yes; };
server 0000::/3 { bogus yes; };
server fe80::/16 { bogus yes; };
server 169.254.0.0/16 { bogus yes; };
# refuse attempts to funnel requests into private/backbone space
server 172.18.53.1/32 { bogus no; }; # whitelisting example
server 172.18.53.2/32 { bogus no; }; # whitelisting example
server 192.168.0.0/16 { bogus yes; };
server 10.0.0.0/8 { bogus yes; };
server 172.16.0.0/12 { bogus yes; };
server 100.64.0.0/10 { bogus yes; };
Um registro que aponta para 127.0.0.1 é um risco de segurança, pois possibilita ataques XSS. Mais informações: link