2. Regole

Quando un resolver DNS con cache iterativa riceve una risposta NXDOMAIN, dovrebbe memorizzarla nella sua cache (SHOULD) e, successivamente, tutti i nomi e gli insiemi di record di risorse (RRset) su o al di sotto di quel nodo dovrebbero essere considerati irraggiungibili (SHOULD). Le query successive per tali nomi dovrebbero produrre una risposta NXDOMAIN (SHOULD).

Tuttavia, se un resolver ha dati memorizzati nella cache al di sotto del taglio NXDOMAIN, può continuare a inviarli come risposta (MAY) — fino alla scadenza del TTL di questi dati memorizzati nella cache —, poiché ciò può evitare ulteriori elaborazioni quando viene ricevuta una query. La Sezione 6 fornisce maggiori informazioni al riguardo.

Un'altra eccezione è che un resolver convalidante può decidere di implementare il comportamento di "taglio NXDOMAIN" (descritto nel primo paragrafo di questa sezione) solo quando la risposta NXDOMAIN è stata convalidata con DNSSEC (MAY). Per la motivazione, si veda la Sezione 7.

Il fatto che un sottoalbero non esista non è per sempre: [RFC2308], Sezione 3, descrive già la quantità di tempo per cui una risposta NXDOMAIN può essere memorizzata nella cache (il "TTL negativo").

Se la risposta NXDOMAIN dovuta a una non esistenza memorizzata nella cache proviene da una zona firmata con DNSSEC, allora sarà accompagnata da record NSEC o NSEC3 che autenticano la non esistenza del nome. Per un nome discendente del nome NXDOMAIN originale, lo stesso insieme di record NSEC o NSEC3 prova la non esistenza del nome discendente. Il resolver iterativo con cache deve restituire questi record NSEC o NSEC3 nella risposta alla query che ha innescato la risposta (MUST), se la query aveva il bit DNSSEC OK (DO) impostato.

Attenzione: se esiste una catena di CNAME (o DNAME), il nome che non esiste è l'ultimo della catena ([RFC6604]) e non il QNAME. Il NXDOMAIN memorizzato nella cache è relativo al nome negato, non sempre al QNAME.

Come esempio della conseguenza di queste regole, si considerino due query successive a un resolver con un dominio inesistente 'foo.example': la prima è per 'foo.example' (che produce un NXDOMAIN) e la seconda per 'bar.foo.example' (che produce anch'essa un NXDOMAIN). Molti resolver oggi inoltrano entrambe le query. Tuttavia, seguendo le regole di questo documento ("taglio NXDOMAIN"), un resolver memorizzerebbe nella cache la prima risposta NXDOMAIN, come segno di non esistenza, e restituirebbe poi immediatamente una risposta NXDOMAIN per la seconda query, senza trasmetterla a un server autoritativo.

Se la prima richiesta è per 'bar.foo.example' e la seconda per 'baz.foo.example', allora la prima risposta NXDOMAIN non dirà nulla su 'baz.foo.example'; pertanto, la seconda query sarà trasmessa come lo era prima dell'uso dell'ottimizzazione "taglio NXDOMAIN" (si veda l'Appendice A).