DNS curinga e /etc/resolv.conf problema

Question

Eu pesquisei através do google.com mas não consigo encontrar uma resposta ... Então eu perguntei aqui.

Este é o problema:

Eu construo um ambiente de teste de DNS no meu PC cujo hostname é gamepc .

O servidor DNS (bind9) tem um registro curinga:

* IN A 192.168.0.1

E o arquivo /etc/resolv.conf tem uma entrada:

domain bogus.
nameserver 127.0.0.1

Então quando eu pingar somehost ele retornará como:

PING somehost.bogus (192.168.0.1) 56(84) bytes of data.
64 bytes from gamepc.bogus (192.168.0.1): icmp_req=1 ttl=64 time=0.042 ms
...

E quando eu pingar google.com ele retornará como:

PING google.com (74.125.71.99) 56(84) bytes of data.
64 bytes from hx-in-f99.1e100.net (74.125.71.99): icmp_req=1 ttl=51 time=68.0 ms
...

Até agora, tudo está bem. Mas se eu pingar algum domínio não existente, por exemplo sldfjsldjflksdjf.com ainda retornará como:

PING sldfjsldjflksdjf.com.bogus (192.168.0.1) 56(84) bytes of data.
64 bytes from gamepc.bogus (192.168.0.1): icmp_req=1 ttl=64 time=0.043 ms
...

E o resultado esperado deve ser:

ping: unknown host sldfjslkdfjlksdjfklsdjf.com

Eu posso pensar como isso aconteceu. No início, o resolvedor tenta sldfjslkdfjlksdjfklsdjf.com , mas recebe uma resposta NXDOMAIN . Em seguida, anexe a parte do domínio e tente sldfjslkdfjlksdjfklsdjf.com.bogus novamente. Desta vez, o nome do host corresponderá ao registro curinga no servidor DNS e retornará 192.168.0.1 ...

Alguém tem o mesmo problema? E como você resolveu isso?

Muito obrigado pela leitura!

    

Answer 1

Does anyone have the same issue?

Todos têm o problema. É uma parte padrão da maioria das bibliotecas de clientes DNS. É chamado de um caminho de pesquisa de domínio ou caminho de pesquisa DNS ou DNS devolution .

And how did you resolve it?

Usando nomes de domínio totalmente qualificados , onde eu desejar. Você não está usando FQDNs.

the browser don't use FQDN to resolve host domain name

Esta é sua primeira menção ao navegador WWW. Você não mencionou isso na pergunta. Os navegadores WWW são esquisitices, até porque eles têm dois, às vezes mais, caminhos de busca de domínio operando um em cima do outro. As pessoas usam usam nomes de domínio totalmente qualificados em URLs exatamente por esse motivo. Se você for configurar sua biblioteca de clientes DNS de modo que seu mecanismo de caminho de pesquisa mapeia com sucesso os nomes para endereços como este, você também terá que fazer isso. Essa é a consequência da sua escolha de ter um caminho de pesquisa e um caractere curinga que corresponda a tudo em uma subárvore inteira. É preciso pensar sobre o uso de curingas.

    

Answer 2

De man resolv.conf :

domain Local domain name.
   Most  queries  for names within this domain can use short names relative 
   to the local domain. If no domain entry is present, the domain is 
   determined from the local hostname returned by gethostname(2); the domain 
   part is taken to be everything after the first '.'.  Finally, if the 
   hostname does not contain a domain part, the root domain is assumed.

search Search list for host-name lookup.
   The search list is normally determined from the local domain name; 
   by default, it  contains  only the  local  domain name. (...)

Portanto, se você consultar sldfjslkdfjlksdjfklsdjf , a ligação não encontrará nenhum registro correspondente, então o seu resolvedor tenta sldfjslkdfjlksdjfklsdjf.bogus , que por sua vez retorna um endereço.

Se você pingar sldfjslkdfjlksdjfklsdjf. (observe o ponto final), você deve estar OK (ou seja, a pesquisa falhará). O ponto final significa que você forneceu um FQDN do host, portanto, nenhum sufixo de domínio deve ser tentado.

    

Answer 3

Eu não acho que você pode realmente resolver o problema devido ao fato de que você tem o curinga em sua configuração de DNS.

Quando não estiver usando o caractere curinga, você receberá a mensagem de erro, mas com as opções curinga e resolv.conf, tudo que for desconhecido será resolvido para o seu domínio.