Quanto dura in genere la cache DNS negativa?

44

Se un server DNS cerca un record e manca, spesso "memorizza nella cache" negativamente il fatto che questo record sia mancante e non proverà a cercarlo di nuovo per un po '. Non vedo nulla nella RFC sul TTL sulla cache negativa dovrebbe essere, quindi immagino che sia in qualche modo arbitrario. Nel mondo reale, per quanto tempo restano questi record negativi?

domain-name-system 
— Leopd
fonte
6
— Skyhawk,

Risposte:

60

Il TTL per la memorizzazione nella cache negativa non è arbitrario. È tratto dal record SOA nella parte superiore della zona a cui il record richiesto sarebbe appartenuto, se fosse esistito. Per esempio:

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

L'ultimo valore nel record SOA ("86400") è la quantità di tempo in cui viene richiesto ai client di memorizzare nella cache i risultati negativi example.org..

Se un client lo richiede doesnotexist.example.org., memorizzerà nella cache il risultato per 86400 secondi.

— Celada
fonte
1
@MarcusAdams ... e un client non memorizzerà nella cache i record su SERVFAIL. Il TTL nel record SOA è, infatti, utilizzato per la memorizzazione nella cache negativa. Ecco perché il record SOA è prodotto nelle risposte NXDOMAIN.
— Celada,
3
@MarcusAdams Correct. Se ottieni un SERVFAIL, non ottieni SOA né TTL. Non ci sono risposte per la cache negativa. Se invece si ottiene un NXDOMAIN di quello che fa ottenere una SOA, con un TTL. Memorizzerai nella cache quella risposta per tutta la durata del TTL.
— Celada,
Beartrap per utenti DNS RBL: poiché le risposte RBL tendono ad essere minime (e l'implementazione del server DNS potrebbe non essere conforme) potresti non ottenere una SOA con la risposta NXDOMAIN. Questo può significare che la tua cache DNS non memorizza affatto nella cache NXDOMAIN (ovvero i non spammer): - /
— mr.spuratic
In realtà MIN(SOA TTL, SOA.MINIMUM), non semplicemente SOA.MINIMUM. (Vedi tools.ietf.org/html/rfc2308#section-5 )
— Håkan Lindqvist
12

Ciò dipende dalla definizione esatta di "query negativa", ma in entrambi i casi, questo è documentato in rfc2308 «Memorizzazione nella cache negativa delle query DNS (DNS NCACHE)» :

NXDOMAIN

  • Se la risoluzione ha esito positivo e risulta NXDOMAIN, la risposta arriverà con un SOArecord, che conterrà il NXDOMAINTTL (tradizionalmente noto come MINIMUMcampo). rfc2308#section-4

SERVFAIL

  • Se la risoluzione non ha esito positivo e si traduce in un timeout ( SERVFAIL) , potrebbe anche non essere affatto memorizzata nella cache e, in ogni caso, NON DEVE essere memorizzata nella cache per più di 5 minuti. rfc2308#section-7.1

    In pratica, la memorizzazione nella cache di tali risultati per i 5 minuti pienamente consentiti è un ottimo modo per ridurre l'esperienza di un client qualora il loro server cache occasionalmente dovesse presentare brevi problemi di connettività (e renderlo effettivamente vulnerabile a un'amplificazione Denial of Service, dove alcuni secondi di inattività comporterebbero il blocco di alcune parti del DNS per i cinque minuti completi).

    Prima di BIND 9.9.6-S1 (rilasciato nel 2014), a quanto pare, SERVFAILnon era affatto memorizzato nella cache. a878301(2014/09/04)

    Ad esempio, al momento della domanda e in tutte le versioni di BIND rilasciate prima del 2014, il risolutore ricorsivo BIND NON ha memorizzato SERVFAILnella cache affatto, se si ritiene che il commit di cui sopra e la documentazione sulla prima introduzione in 9.9.6-S1 .

    Nell'ultimo BIND, l'impostazione predefinita servfail-ttlè 1se l'impostazione è hardcoded su un limite di 30s(al posto del limite di RFC obbligatorio di 300s). 90174e6(2015/10/17)

    Inoltre, le seguenti sono alcune citazioni degne di nota in materia:

    Il risultato della memorizzazione nella cache delle risposte SERVFAIL ha incluso alcune situazioni in cui è stato ritenuto dannoso per l'esperienza del cliente, in particolare quando le cause del SERVFAIL presentate al cliente erano transitorie e da uno scenario in cui un nuovo tentativo immediato della query sarebbe un azione più appropriata.

    La seconda tattica è affermare che i client DNS diffusi faranno qualcosa di particolarmente malvagio quando non saranno in grado di raggiungere tutti i server DNS. Il problema con questo argomento è che l'affermazione è falsa. Qualsiasi client di questo tipo è chiaramente difettoso e non sarà in grado di sopravvivere sul mercato: considera cosa succede se i router del client si interrompono brevemente o se la rete del client viene temporaneamente allagata.

In sintesi, una NXDOMAINrisposta verrebbe memorizzata nella cache come specificato nella SOAzona applicabile, mentre SERVFAILè improbabile che venga memorizzata nella cache o, se memorizzata nella cache, sarà al massimo un numero di due cifre di secondi.

— CNST
fonte
1

Esiste un RFC dedicato a questo argomento: RFC 2308 - Memorizzazione nella cache negativa delle query DNS (DNS NCACHE) .

La sezione pertinente da leggere è 5: memorizzazione nella cache delle risposte negative che afferma:

Come le risposte normali, le risposte negative hanno il tempo di vivere (TTL). Poiché nella sezione di risposta non è presente alcun record a cui applicare questo TTL, il TTL deve essere portato con un altro metodo. Questo viene fatto includendo il record SOA della zona nella sezione autorità della risposta. Quando il server autorevole crea questo record, il suo TTL viene preso dal minimo del campo SOA.MINIMUM e dal TTL di SOA. Questo TTL diminuisce in modo simile a una normale risposta memorizzata nella cache e al raggiungimento di zero (0) indica che la risposta negativa memorizzata nella cache NON DEVE essere utilizzata nuovamente.

Innanzitutto, consente di identificare il SOA.MINIMUMTTL SOA e descritto nella RFC. Il TTL è il numero prima del tipo di record IN( 900secondi nell'esempio seguente). Mentre il minimo è l'ultimo campo nel record ( 86400secondi nell'esempio seguente).

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

Ora diamo un'occhiata ad alcuni esempi, la serverfault.comzona è illustrativa in quanto ha server autorevoli di due diversi provider configurati in modo diverso.

Consente di trovare i nameserver autorevoli per la serverfault.comzona:

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

Quindi controlla il record SOA usando un nameserver aws:

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Da questo possiamo vedere che il TTL del record SOA è 900secondi mentre il valore TTL negativo è 86400secondi. Il valore SOL TTL di 900è inferiore, quindi prevediamo di utilizzare questo valore.

Ora se interrogiamo un server autorevole per un dominio inesistente dovremmo ottenere una risposta senza risposta e con un record SOA nella sezione autorità:

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

Quando un risolutore ricorsivo (memorizzazione nella cache) riceve questa risposta, analizzerà il record SOA nel AUTHORITY SECTIONe utilizzerà il TTL di questo record per determinare per quanto tempo dovrebbe memorizzare nella cache il risultato negativo (in questo caso 900secondi).

Ora seguiamo la stessa procedura con un nameserver google:

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

Puoi vedere che i nameserver di Google hanno valori diversi sia per i valori TTL SOA che per quelli TTL negativi. In questo caso il TTL negativo di 300è inferiore al TTL SOA di 21600. Pertanto, il server di Google dovrebbe utilizzare il valore più basso nel AUTHORITY SECTIONrecord SOA quando restituisce una NXDOMAINrisposta:

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

Come previsto, il TTL del record SOA nella NXDOMAINrisposta è 300secondi.

L'esempio sopra mostra anche quanto sia facile ottenere risposte diverse alla stessa query. La risposta che finisce per utilizzare un singolo risolutore di cache è la richiesta a namserver autorevole.

Nei miei test ho anche osservato che alcuni risolutori ricorsivi (memorizzazione nella cache) non restituiscono un AUTHORITY SECTIONcon un record SOA con un TTL decrementante per le richieste successive, mentre altri lo fanno.

Ad esempio il risolutore cloudflare fa (notare il valore TTL decrementante):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Mentre il resolver predefinito in un VPC AWS risponderà con una sezione di autorità solo alla prima richiesta:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Nota: questa risposta risolve il comportamento delle NXDOMAINrisposte.

Glossario:

— htaccess
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.