Adicionar um nome de host com 'www' à entrada TXT no servidor de nomes torna o site indisponível - por quê?

Question

Uma forma de verificar sites ao usar as ferramentas do Google para webmasters é adicionar uma entrada TXT ao servidor de nomes, usando o nome do host e adicionando o texto fornecido.

Por acaso (porque simplesmente não sabia) adicionei duas entradas TXT, uma com 'www' e outra sem, apenas para garantir que o Google aceitaria o código (porque nas ferramentas para webmasters o site foi inserido com 'www').

O que aconteceu foi: depois que as entradas de DNS se espalharam, os sites não estavam mais disponíveis ao usar o nome do host com 'www'. EDITAR: Nenhuma mensagem de erro em particular, apenas "Servidor não encontrado".

Por quê? Provavelmente foi ingênuo pensar que o formato de entrada TXT é um pouco arbitrário, mas alguém pode explicar a um desenvolvedor chocado (= não-administrador) por que um registro TXT pode influenciar algo que deveria ser manipulado por registros tão destrutivamente?

EDITAR: Aqui está o exemplo (mas é claro que não está mais online). O site é hospedado em domainfactory, um hoster compartilhado onde é possível editar as configurações de DNS (ou ter o domainfactory gerenciando-as - nesse caso, a coluna 'Ziel' mostra seu nome; geralmente não é problema misturar entradas):

É exatamente a última entrada que tornou o site indisponível.

No entanto, dizer-me que isso não deveria acontecer também é uma boa resposta - posso perguntar ao provedor de hospedagem.

Perdoe-me se eu não estiver familiarizado com o nslookup, mas fiz uma pesquisa com um sem www em um dos domínios que ainda não funcionam, e este é o resultado:

C:\>nslookup www.foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Name:    www.foo.de

E o segundo:

C:>nslookup foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Nicht autorisierende Antwort:
Name:    foo.de
Address:  81.20.84.178

A diferença é que a solicitação sem 'www' mostrou um 'Antidicção autoritizada de Nicht:' (provavelmente 'resposta não autorizadora'), mas o IP correto.

    

Answer 1

OK, eu posso duplicar o comportamento (BIND 9.6) e acreditar que descobri a causa:

Se você tiver um curinga Um registro e um registro TXT mais específico, como abaixo do registro A.

*.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

mas se você tiver um registro específico A, ele funcionará bem:

*.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

Portanto, aparentemente ter um registro mais específico (mesmo de um tipo diferente) mascara o registro curinga A.

Não sei qual é a lógica subjacente que faz com que o curinga A record não seja reconhecido se houver um registro TXT mais específico, ou se for uma coisa obrigatória de RFC ou não, mas você pode ler os RFCs do DNS (e / ou a fonte BIND) para mais detalhes.

    

Answer 2

Porque fica no caminho do seu registro curinga (" * "). Se você tiver algum registro para um item, o curinga não corresponderá mais a nenhum tipo de registro.

De RFC1034 , §4.3.3:

Wildcard RRs do not apply … [w]hen the query name or a name between the wildcard domain and the query name is [known] to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X.

Observe que o exemplo não corresponde à situação do OP, mas a regra é a mesma.

    

Answer 3

É possível que, durante a edição da zona, você acidentalmente tenha removido um registro A de um CNAME?

Talvez seja útil dar uma olhada no seu arquivo Zone completo e ver se tudo o que você espera estar lá ainda está lá?