Não consolidado - domínios armazenados em cache apenas por pouco tempo

Question

Recentemente, configurei o Unbound para caching DNS, junto com o DNScrypt no Linux Mint 18.1. Funciona, mas notei que as páginas só são armazenadas em cache por pouco tempo:

1. Primeira consulta a google.com - 48ms (domínio não armazenado em cache)
2. Segunda consulta ao google.com (imediatamente depois disso) - 0ms (domínio em cache)
3. Terceira consulta a google.com (após ~ minuto) - 46ms (domínio não armazenado em cache)

Este comportamento é pretendido ou preciso definir algo diferente para armazenar em cache páginas por mais tempo? Aqui está minha configuração do Unbound (/etc/unbound/unbound.conf):     #

 Unbound configuration file for Debian.
    #
    # See the unbound.conf(5) man page.
    #
    # See /usr/share/doc/unbound/examples/unbound.conf for a commented
    # reference config file.age
    #
    # The following line includes additional configuration files from the
    # /etc/unbound/unbound.conf.d directory.
    include: "/etc/unbound/unbound.conf.d/*.conf"
    server:
        verbosity: 1
        num-threads: 4
        outgoing-range: 8192
        so-rcvbuf: 4m
        so-sndbuf: 4m
        so-reuseport: yes
        msg-cache-size: 50m
        msg-cache-slabs: 16
        num-queries-per-thread: 4096
        rrset-cache-size: 100m
        rrset-cache-slabs: 16
        infra-cache-slabs: 16
        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes
        do-daemonize: yes
        hide-identity: yes
        hide-version: yes 
        harden-short-bufsize: yes
        harden-large-queries: yes
        harden-glue: yes
        harden-dnssec-stripped: yes
        harden-below-nxdomain: yes
        harden-referral-path: yes
        logfile: "/etc/unbound/unbound.log"
        use-caps-for-id: yes
        do-not-query-localhost: no
        prefetch: no 
    forward-zone:
        name: "."
        forward-addr: 127.0.0.1@40

    

Answer 1

Não vinculado (ou pelo menos deveria) estar armazenando em cache o resultado pelo tempo especificado no TTL para o registro que você está solicitando.

Isso é exatamente o que eu observo em um sistema que tenho para entregar e que está solto. A solicitação inicial leva 14ms, as solicitações subsequentes levam 0ms e, quando o TTL expira, a próxima solicitação leva 14ms.

Solicitação inicial que mostra um TTL de 300 segundos e leva 18ms

;; ANSWER SECTION:
google.com.             300     IN      A       172.217.20.46

;; Query time: 18 msec
;; SERVER: 10.34.20.1#53(10.34.20.1)
;; WHEN: Sun Feb 12 20:39:30 2017
;; MSG SIZE  rcvd: 44

Pedidos subseqüentes - TTL está em contagem regressiva e leva 0ms

;; ANSWER SECTION:
google.com.             196     IN      A       172.217.20.46

;; Query time: 0 msec
;; SERVER: 10.34.20.1#53(10.34.20.1)
;; WHEN: Sun Feb 12 20:41:14 2017
;; MSG SIZE  rcvd: 44

O TTL expirou para que outro pedido de upstream seja feito 23ms

;; ANSWER SECTION:
google.com.             300     IN      A       172.217.20.46

;; Query time: 23 msec
;; SERVER: 10.34.20.1#53(10.34.20.1)
;; WHEN: Sun Feb 12 20:44:37 2017
;; MSG SIZE  rcvd: 44