Início / server / Perguntas / 800071
Accepted
Lawrence Wagerfield
Asked: 2016-08-31 12:37:46 +0800 CST

Como fazer o DIG honrar TTLs / usar o cache local do sistema operacional?

  • 772

Quando executo, dig example.coma resposta retorna com SERVER: 192.168.0.1, mesmo nas execuções subsequentes. Isso implica que o DIG está sempre fazendo uma chamada de rede para resolver o registro DNS.

Eu (um tanto ignorantemente) presumi que meu sistema operacional estaria armazenando em cache o registro DNS de acordo com seu TTL e que o DIG estaria usando esse cache.

O DIG ignora o TTL/não faz uso de caches por padrão? Em caso afirmativo, como posso fazer com que o DIG use um cache e honre os TTLs?

Antecedentes / Problema XY:

Eu quero uma maneira de resolver rapidamente os registros DNS TXT para um script nginx que estou escrevendo. O script encaminhará as solicitações com base no conteúdo desses registros TXT, portanto, gostaria que o método que estou usando respeitasse os TTLs e usasse registros armazenados em cache localmente quando apropriado.

domain-name-system networking nginx linux-networking dig

2 respostas

  1. Best Answer

    dig (apalpador de informações de domínio), como explica o manual, é uma ferramenta flexível para interrogar servidores de nomes DNS , não consulta ou usa seu cache DNS local (e/ou hostsarquivo), mas consulta diretamente o servidor de nomes para o qual você o aponta. Por padrão, esse será o(s) de /etc/resolv.conf.

    Para usar o cache DNS do seu sistema a partir da linha de comando, use getent hosts [ip-address | hostname]ou em scripts/código, use uma versão nativa da man 3 gethostbynamechamada do sistema.

    Reconhecidamente, isso não ajuda você com mais nada além A AAAAou PTRregistros.

    Na digsaída, o rótulo SERVER é o endereço IP do servidor dig de nomes usado, que nunca terá um TTL...

    dig ANY www.google.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27695
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.                IN      A

;; ANSWER SECTION:
www.google.com.     173     IN      A       216.58.212.132


;; AUTHORITY SECTION:
google.com.         146915  IN      NS      ns2.google.com.
google.com.         146915  IN      NS      ns3.google.com.
google.com.         146915  IN      NS      ns1.google.com.
google.com.         146915  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     145115  IN      A       216.239.34.10
ns1.google.com.     145115  IN      A       216.239.32.10
ns3.google.com.     145115  IN      A       216.239.36.10
ns4.google.com.     145115  IN      A       216.239.38.10

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)    <========== My Name SERVER is localhost
;; WHEN: Tue Aug 30 22:51:26 2016
;; MSG SIZE  rcvd: 184

    Eu executo meu próprio servidor DNS de cache localmente, em vez de usar um resolvedor público do ISP ou do Google (8.8.8.8), principalmente para spamassassin, que tem a vantagem de ser local, mas o cache também não é pré-semeado/preenchido por outros usuários .

    • 4

  2. Esta é realmente uma questão de resolução de sistema operacional, mas você não especificou o sistema operacional. Como digé mencionado, vou presumir que estamos trabalhando com algum tipo de UNIX aqui.

    Os sistemas operacionais baseados em UNIX não implementam um cache DNS dentro do próprio kernel. Existem alguns tópicos que precisam ser resumidos antes de entrarmos em como isso é realmente implementado.

    NSS

    As chamadas para a biblioteca do resolvedor geralmente implementam suas pesquisas usando Name Service Switch (NSS), um sistema modular para especificar fontes de dados a serem usadas e a ordem em que são pesquisadas. Você pode encontrar uma lista dessas pilhas de módulos em /etc/nsswitch.conf. Para referência, aquele com o qual estamos preocupados aqui é hosts.

    Não é recomendado brincar com a hostsentrada a /etc/nsswitch.confmenos que você realmente saiba o que está fazendo. Reordenar esses módulos pode resultar em coisas esquisitas como DNS consultado antes do /etc/hostsarquivo!

    nscd

    Antes de consultar a pilha de módulos, o NSS verifica a presença de um nscdsoquete em execução e tenta consultá-lo. Se nscdestiver configurado para manter um cache para o banco de dados NSS em questão, é possível que uma entrada em cache nscdseja retornada sem que os módulos NSS sejam consultados. A maioria das distribuições Linux que conheço não habilitam o cache do hostsbanco de dados por padrão e /etc/nscd.confdevem ser personalizadas.

    Dito isso, deve-se notar que muitos administradores consideram o nscddaemon "stock" não confiável, pelo menos no Linux. Há pelo menos uma implementação alternativa por aí. Sua milhagem pode variar.

    Juntando tudo

    Sabendo do exposto, a ordem de pesquisa para o banco de dados de hosts funciona nesta ordem:

    • nscd(se estiver em execução, seu soquete está presente e o cache de hosts está ativado)
    • Módulos NSS, na ordem listada em/etc/nsswitch.conf
    • Se não for encontrado em um módulo NSS, ele não existe.

    Isso nos leva a onde digse enquadra nessa equação. Você pode se referir a toda a resposta do HBrujin ( dignão usa NSS, apenas fala sobre TCP / IP), mas o problema é que não há cache para NSS, a menos que 1) nscdesteja em execução e 2) esteja configurado para armazenar em cache o hostsbanco de dados.

    tl;dr

    A complexidade de fazer com que o cache DNS funcione bem no NSS geralmente é o motivo pelo qual a maioria dos administradores adota a solução "mais simples" de executar seu próprio servidor DNS recursivo. Você não precisa saber nada sobre NSS. Apenas aponte /etc/resolv.confpara o seu novo cache DNS brilhante e deixe-o esconder os males do NSS de você. (pelo menos até você precisar aprender como funciona a integração do LDAP)

    • 2

relate perguntas