O DNS apenas começou a resolver meus endereços server.prod para 127.0.53.53

38

Eu tenho servidores com o nome like server.prod.example.come faço logon regularmente como server.prod. Recentemente, esses nomes de host começaram a ser resolvidos para 127.0.53.53.

Acontece que a ICANN ativou recentemente o .prodTLD. Além disso, todas as solicitações .prodenviadas aos servidores de nomes são resolvidas para 127.0.53.53, em vez de retornar como NXDOMAIN, o que permitiria que a resolução continuasse funcionando corretamente. (Acho que o ponto por trás disso é deixar as pessoas saberem que suas coisas piorarão antes que elas comecem a resolver algo real.)

Como evitar ter que digitar meu nome de domínio para cada host como este?

Isso ainda está mordendo você ocasionalmente? Não consegui encontrar uma lista de novos TLDs e quando eles foram adicionados, então eu mesmo configurei um: https://twitter.com/newgtldannounce

domain-name-system tld wfaulk
fonte
5
Essa alteração da ICANN também serve como um bom lembrete de que deixar seus aplicativos usar caminhos de pesquisa é ruim. Embora essa pergunta definitivamente tenha mérito para quando a entrada de um usuário resultar nesse comportamento, é melhor que seus aplicativos usem entradas de arquivo host ou FQDNs com sufixo de ponto. Poucos percebem que o glibc não passará para o próximo servidor até que o tempo limite seja excedido na tentativa de cada sufixo de pesquisa definido.
Andrew B
13
Permitam-me apenas um momento para lembrar a todos que .prodé um TLD idiota . :(
Lightness Races com Monica
Sua pergunta respondeu à pergunta que eu ia fazer, dizendo "ICANN ativou recentemente o <LDW> qualquer TLD". Acontece que eu estava usando .haus para minha LAN e começou a receber estes: D Obrigado por perguntar / responder :)
Arno Teigseth
2
O @LightnessRacesinOrbit .prod é um dos muitos TLDs novos do Google. Culpe-os.
Michael Hampton
@LightnessRacesinOrbit pode ser estúpido se você olhar dessa maneira, mas, ao mesmo tempo, não é bom depender das listas de pesquisa ou usar nomes não registrados globalmente, pois você poderá colidir.
Patrick Mevzek

Respostas:

37

Quando você vê domínios internos resolverem repentinamente 127.0.53.53ter uma colisão de nomes, a ICANN está tentando lhe dizer que você precisa corrigir urgentemente sua configuração de DNS.
Se ele retornasse NXDOMAIN como você sugeriu, você está correto, continuaria funcionando - por enquanto .

Também vazaria sua consulta DNS pretendida internamente para terceiros.

Pior, no futuro alguém poderá se registrar server.prode causar muito mais problemas.

Veja aqui para mais informações https://icann.org/namecollision ou execute:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

Quanto a como resolver isso: Depende do caso de uso, eu provavelmente os adicionaria .ssh/configcom os nomes abreviados. Ou comece a usar os FQDNs realmente.

falsificador
fonte
5
@MichaelHampton não realmente, eu recomendo o capítulo 5.3: Train users and system administrators in using FQDNs;)
faker
3
Sim, porque eu realmente quero, 20 vezes por dia, digitar em ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comvez de ssh db.
wfaulk
3
@wfaulk: Por que seria uma "piada"? Se você não gosta de digitar excessivamente, por que está obsessivamente evitando o melhor mecanismo para permitir a interação com um computador que evita digitação excessiva? Alguns de vocês, nerds do Unix, são apenas desagradáveis.
Lightness Races com Monica
4
@Lightness Geralmente porque tendemos a gravitar em direção a hosts do bastião. Nossos senhores corporativos têm cada vez menos probabilidade de permitir que seus funcionários executem um Unix nos dispositivos emitidos pela empresa com o passar dos anos, e as horas de trabalho economizadas por ter acesso a scripts de shell do nosso ponto de acesso superam facilmente o que uma GUI oferece . GUI e consoles de texto têm sua parcela de maus hábitos associados a eles. : P
Andrew B
4
Este não é o lugar para ter uma discussão GUI vs CLI. Propus uma solução, pode não ser a melhor para todos e é tudo o que há para dizer.
quer
13

Se você digitar um nome de host sem pontos, os resolvedores de DNS tentarão procurar esse nome de host anexando primeiro os domínios de pesquisa configurados.

Para a maioria dos resolvedores, se você usar um nome de host com pelo menos um ponto, o resolvedor primeiro tenta o nome do host por conta própria e volta a anexar os domínios de pesquisa configurados.

Muitos resolvedores podem alterar seu comportamento para anexar os domínios de pesquisa aos nomes de host com pontos. Isso geralmente ocorre através de uma opção chamada " ndots" que informa ao resolvedor quantos pontos o nome do host deve ter antes de tentar procurar o nome do host sozinho primeiro. Para fazer o server.prodtrabalho, adicione esta linha ao seu resolv.conf:

options ndots:2

Se você também quiser resolver server.subzone.prod, precisará definir a opção como 3 etc.

Se alguém souber como fazer isso funcionar no MacOS X, entre em contato. a mudança /etc/resolv.confestá documentada para não funcionar (e não funciona) e não consigo descobrir os scutilencantamentos certos .

(Nota: estou protegendo minhas apostas aqui mais do que provavelmente é garantido. Acredito que a ndotsopção funcione em 99% dos sistemas Unix (não MacOSX).)

wfaulk
fonte
1
Você está confundindo a biblioteca do resolvedor do SO com o BIND. /etc/resolv.confpertence ao sistema operacional. :)
Andrew B
A maioria, se não todos, os resolvedores do Unix OS são extraídos diretamente das bibliotecas de resolvedores do BIND, se não totalmente, usando-os diretamente. Meu argumento ao chamar BIND é que é possível que exista algum sistema operacional por aí que use algo diferente que não responda à opção "ndots".
wfaulk
2
É mais provável que essa declaração induza as pessoas a pensar que o resolvedor implementado pela biblioteca padrão C depende das bibliotecas fornecidas pelo ISC. No caso da glibc, certamente não .
Andrew B
1
Justo. Corrigido para tentar incorporar que ele pode não funcionar enquanto não faz referência ao BIND.
wfaulk
0

Outras respostas forneceram a solução técnica para o problema. Mas ninguém respondeu à sua:

Não consegui encontrar uma lista de novos TLDs e quando eles foram adicionados

Então aqui está.

Você tem várias maneiras.

  1. Acesse o site da IANA em: https://www.iana.org/domains/root/db ; você verá a lista atual de TLDs delegados, que são os que resolvem e estão na zona raiz. Se você clicar em algum deles, na parte inferior, você receberá uma data informando quando eles apareceram
  2. Esses mesmos dados estão disponíveis whois, por exemplo, no seu caso whois -h whois.iana.org prod | grep created, fornecerá a vocêcreated: 2014-08-23
  3. Existem vários bots no Twitter / Mastodon que são postados quando o conteúdo da IANA é alterado. Consulte, por exemplo, https://twitter.com/ianawhois ou https://twitter.com/rootchanges
  4. Os dados da IANA podem estar um pouco atrasados ​​na atualização, portanto, o banco de dados canônico para gTLDs e para ver em que estágio eles estão (agora é um pouco discutível desde que a rodada de 2012 da ICANN de introdução de novos gTLDs está praticamente concluída, mas novas rodadas serão concluídas. chegar), está aqui: https://gtldresult.icann.org/application-result/applicationstatus ; Você pode pesquisar por TLD. Todos os gTLDs também têm um período inicial específico, portanto, você encontrará dados aqui: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods, você pode exportar todos os dados.
  5. Você também pode usar os dados da ICANN no JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json
Patrick Mevzek
fonte