Consultas DNS que não usam o nscd para armazenamento em cache

9

Estou tentando usar o nscd (Daemon Cache de Servidores) para armazenar o DNS localmente, para que eu possa parar de usar o Bind para fazer isso. Eu comecei e ntpd parece tentar usá-lo. Mas tudo o mais para os hosts parece ignorar isso. por exemplo, se eu cavar o apache.org 3 vezes, nenhum deles acessará o cache. Estou visualizando as estatísticas do cache usando nscd -g para determinar se ele foi usado. Eu também mudei o nível de log de depuração para ver se consigo vê-lo acertando e as consultas nem sequer acertam o nscd.

nsswitch.conf

# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files

publickey: files

hosts: cache files dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files
# End /etc/nsswitch.confenter code here

nscd.conf

#
# /etc/nscd.conf
#
# An example Name Service Cache config file.  This file is needed by nscd.
#
# Legal entries are:
#
#       logfile                 <file>
#       debug-level             <level>
#       threads                 <initial #threads to use>
#       max-threads             <maximum #threads to use>
#       server-user             <user to run server as instead of root>
#               server-user is ignored if nscd is started with -S parameters
#       stat-user               <user who is allowed to request statistics>
#       reload-count            unlimited|<number>
#       paranoia                <yes|no>
#       restart-interval        <time in seconds>
#
#       enable-cache            <service> <yes|no>
#       positive-time-to-live   <service> <time in seconds>
#       negative-time-to-live   <service> <time in seconds>
#       suggested-size          <service> <prime number>
#       check-files             <service> <yes|no>
#       persistent              <service> <yes|no>
#       shared                  <service> <yes|no>
#       max-db-size             <service> <number bytes>
#       auto-propagate          <service> <yes|no>
#
# Currently supported cache names (services): passwd, group, hosts, services
#

    logfile                 /var/log/nscd.log
    threads                 4
    max-threads             32
    server-user             nobody
#   stat-user               somebody
    debug-level             9
#   reload-count            5
    paranoia                no
#   restart-interval        3600

    enable-cache            passwd          yes
    positive-time-to-live   passwd          600
    negative-time-to-live   passwd          20
    suggested-size          passwd          211
    check-files             passwd          yes
    persistent              passwd          yes
    shared                  passwd          yes
    max-db-size             passwd          33554432
    auto-propagate          passwd          yes

    enable-cache            group           yes
    positive-time-to-live   group           3600
    negative-time-to-live   group           60
    suggested-size          group           211
    check-files             group           yes
    persistent              group           yes
    shared                  group           yes
    max-db-size             group           33554432
    auto-propagate          group           yes

    enable-cache            hosts           yes
    positive-time-to-live   hosts           3600
    negative-time-to-live   hosts           20
    suggested-size          hosts           211
    check-files             hosts           yes
    persistent              hosts           yes
    shared                  hosts           yes
    max-db-size             hosts           33554432

    enable-cache            services        yes
    positive-time-to-live   services        28800
    negative-time-to-live   services        20
    suggested-size          services        211
    check-files             services        yes
    persistent              services        yes
    shared                  services        yes
    max-db-size             services        33554432

resolv.conf

# Generated by dhcpcd from eth0
nameserver 127.0.0.1
domain westell.com
nameserver 192.168.1.1
nameserver 208.67.222.222
nameserver 208.67.220.220

como uma nota secundária, estou usando o Arch Linux.

nota: isso foi movido duas vezes, eu nunca descobri por que os aplicativos, excluindo dig, não estão atingindo o cache nscd, navegadores, mensagens instantâneas, IRC, tudo deveria ter sido, mas eles não fizeram

    
por xenoterracide 10.04.2010 / 02:20

6 respostas

13

O motivo pelo qual você está perdendo as ocorrências de cache é que as consultas de escavação do DNS diretamente. Você pode tentar e ver se o cache funciona com o comando getent :

getent hosts host.example.com

Executar um DNS separado em cache é uma boa ideia, mas você deve considerar executá-lo no nível da rede, se possível. Se cada host armazenar em cache os dados separadamente, eles ainda executarão várias consultas para os mesmos hosts. O cache único funciona em torno desse problema.

O próprio nscd é um daemon de armazenamento em cache para funções do NSS. Portanto, o foco é um pouco diferente dos servidores de nome de armazenamento em cache nativos. Portanto, se você quiser apenas um servidor de nomes de armazenamento em cache, use algo diferente do nscd. Se, em vez disso, você quiser colocar em cache coisas como nomes de usuários e dados de host compartilhados fora do sistema DNS normal, vá para nscd.

E para o registro, eu gostei bastante do resolvedor powerdns (pdns-resolver).

    
por 30.07.2010 / 11:18
3

Você está sentindo falta da configuração dos hosts no nscd.conf. Estou postando o meu como exemplo:

enable-cache            hosts           yes
positive-time-to-live   hosts           3600
negative-time-to-live   hosts           20
suggested-size          hosts           211
check-files             hosts           yes
persistent              hosts           yes
shared                  hosts           yes
max-db-size             hosts           33554432

Isso vai quebrar algumas coisas. As seguintes informações são do pacote Debian:

  Since this release, hosts caching in nscd is off by default: for some of the
  libc calls (gethostby* calls) nscd does not respect the DNS TTLs.  It can
  lead to system lockups (e.g. if you are using pam-ldap and change the IP of
  your authentication server) hence is not considered safe.

  See debian bug #335476 and how upstream answered to that in
  http://sourceware.org/bugzilla/show_bug.cgi?id=4428.

 -- Pierre Habouzit <[email protected]>  Sat, 28 Apr 2007 11:10:56 +0200
    
por 28.04.2010 / 23:06
2

Eu não sei muito sobre o nscd, exceto que muitas vezes causou problemas com pesquisas de DNS que eu sempre desabilitei (ou pelo menos as pesquisas de host fazem parte disso). O Nscd permite definir os valores do tempo de vida e eu sei que o DNS espera "possuir" esses valores e ter todos os resolvedores honrando-os. Você pode acabar com resultados estranhos se os TTLs no DNS não forem honrados. Minha recomendação é não usar o nscd para armazenar em cache o DNS. Parece que você já tem um servidor de nomes em cache em execução na sua caixa local, portanto, não é necessário armazenar em cache as pesquisas de DNS duas vezes.

    
por 10.04.2010 / 03:41
1

O nscd é realmente pouco confiável para tudo, não apenas DNS. Vale a pena evitar, a menos que você precise desesperadamente por algum motivo. Você deve usar um daemon de armazenamento em cache de DNS feito especificamente se quiser armazenar o DNS em cache localmente (o que é uma boa ideia!).

Dois dos meus favoritos são dnsmasq e dnscache de djbdns .

    
por 05.05.2010 / 03:26
1

Se houver cache de DNS no Inferno, ele será fornecido pelo nscd. Não faça Usar. Isso.

Só para ser diferente: o pdnsd é, na verdade, um ótimo substituto. Ou unscd (usado por padrão pelo menos no openSUSE).

    
por 30.07.2010 / 10:14
1

Gostaria de acrescentar que, quando você tiver compartilhado, suas estatísticas não serão refletidas corretamente:

hosts compartilhados sim

link

Eu não vi mais ninguém mencionando isso e levei algum tempo para descobrir por que minha taxa de hits continuava aparecendo como 0%

    
por 19.02.2017 / 12:36