Pesquisa e domínio em resolv.conf = pesquisas lentas no Ubuntu

Question

Eu tenho uma máquina rodando o ubuntu 10.04 server. Comecei a receber atrasos longos (5-10 segundos) ao fazer conexões com (alguns) sites fora da LAN usando ferramentas como curl e wget .

Usando tcpdump e wireshark, descobri que o problema está nas pesquisas de DNS que estão sendo feitas para configurar a conexão:

EXEMPLO

Quando eu corro:

wget www.site1.com

Eu vejo o seguinte comportamento:

LOOKUP: AAAA www.site1.com       
        # => fail, no delay, site1 doesn't have an IPv6 AAAA record
LOOKUP: AAAA www.site1.com.mydomain.lan
        # => fail, BIG DELAY, crazy domain doesn't exist
LOOKUP: A www.site1.com
        # => success, no delay, resolves as expected (site1 has IPv4 A record)
CONNECTION PROCEEDS ...

MINHA CONFIGURAÇÃO

O resolv.conf do meu servidor é assim:

nameserver 192.168.0.1  # my router
domain mydomain.lan    # made up domain name, for my lan
search mydomain.lan

O arquivo hosts do meu servidor é assim:

127.0.0.1       localhost.localdomain   localhost
192.168.0.10    server1.mydomain.lan   server1
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

RESOLUÇÕES?

Por que minha lista de pesquisa resolv.conf está sendo usada na construção do nome da segunda pesquisa, quando a página de manual resolv.conf sugere que ela é usada apenas para procurar nomes de host (sem pontos):

"Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found."

Estou com a impressão, a segunda pesquisa está errada e não deve ser realizada em todos ...

Se eu remover as linhas domain e search do resolv.conf, a segunda consulta não é mais executada e meus atrasos desaparecem.

(também, se eu forçar o wget a lidar apenas com o IPv4, as pesquisas de AAAA não são feitas, portanto os atrasos desaparecem):

wget --inet4-only www.site1.com

    

Answer 1

Esse comportamento é por design.

O IPv6 está sendo preferido - portanto, o status do recurso em AAAA terms é determinado primeiro. Uma resposta NXDOMAIN volta - então o cliente calcula que precisa anexar o caminho search .

Observe que a observação ndots que você fez está correta, mas não toda a história. Se o número ndots for maior que o nome consultado (se fosse um nome de rótulo único, nesse caso), a única diferença no comportamento da consulta é que a consulta com o sufixo anexado ocorrerá antes o nome bruto é tentado. Como você está acima do limite ndots , o nome é tentado primeiro, conforme fornecido. Veja mais abaixo na página man:

The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it.

Essa consulta falhou, portanto, a lista de pesquisa deve ser usada. Observe a diferença no comportamento da consulta com wget http://site1/ .

O que você está vendo é o comportamento pretendido - o que eu acho que você precisa corrigir é a confluência de fatores que está causando essa pesquisa lenta.

• Corrija seu servidor DNS ou corrija o envio de dados de origem. Um recursor deve armazenar em cache facilmente o NXDOMAIN das raízes quando tentar procurar um TLD inexistente. Desde que o IPv6 é corrigido, você pode ter um servidor DNS no caminho que está falhando miseravelmente no cache quando AAAA de pesquisas estão envolvidas. Tente alterar seu resolvedor para 8.8.8.8 para verificar.
• Pare de adicionar um caminho de pesquisa para uma zona DNS que aparentemente você não pode fazer pesquisas. Se o seu servidor DNS fosse autoritativo para essa zona (que é o que seria necessário para que a configuração search fosse de alguma utilidade, já que não é um nome válido na hierarquia pública), ele responderia imediatamente. Você provavelmente não precisa da configuração search - mas defina-a como algo que será resolvido, para que não tente adivinhá-la a partir do nome do host da máquina. search com deve fazer bem.

Answer 2

Se em um prompt do shell você disser $ hostname e receber de volta foo.bar.baz , o resolvedor DNS entenderá que seu nome de host é foo e seu nome de domínio é bar.baz . Geralmente, as linhas "domain" e "search" em /etc/resolv.conf são úteis se isso não for não verdadeiro (ou se você pretende provocar um comportamento incomum).

Se o seu nome de domínio for realmente bar.baz , então provavelmente você não especificará as linhas "domínio" ou "pesquisa" em /etc/resolv.conf. Ao contrário do que acontece com frequência em outros lugares, em /etc/resolv.conf estar "preparado" ao reespecificar as informações que já estão disponíveis em hostname geralmente produzirá comportamentos bizarros e indesejados (incluindo tempos limite longos). Isso é verdade tanto em grandes ambientes comerciais quanto em pequenos ambientes domésticos.

(Advertência: Cada programa aplicativo pode potencialmente interpretar o /etc/resolv.conf de forma um pouco diferente, então, em teoria, isso pode não ser universalmente verdade. Na maioria dos sistemas modernos, 99% dos pedidos do resolvedor passam pelo GLIBC, assim como questão prática o acima é quase sempre verdade.)