1. Introduzione e contesto
Il protocollo DNS [RFC1035] definisce il codice di risposta 3 come "Name Error" (errore di nome), o "NXDOMAIN" [RFC2308], il che significa che il nome di dominio interrogato non esiste nel DNS. Poiché i nomi di dominio sono rappresentati come un albero di etichette ([RFC1034], Sezione 3.1), la non esistenza di un nodo implica la non esistenza dell'intero sottoalbero radicato in quel nodo.
L'algoritmo di risoluzione iterativa del DNS interpreta il segnale NXDOMAIN esattamente in questo modo. Se incontra un codice di risposta NXDOMAIN da un server autoritativo, interrompe immediatamente l'iterazione e restituisce la risposta NXDOMAIN al richiedente.
Tuttavia, nella maggior parte dei resolver esistenti oggi conosciuti, una non esistenza memorizzata nella cache per un dominio non è considerata una "prova" che non possano esistere domini figli al di sotto. Ciò è dovuto a un'ambiguità in [RFC1034] che non distingueva chiaramente i nomi di non terminale vuoto (Empty Non-Terminal, ENT) ([RFC7719]) dai nomi inesistenti (Sezione 3.1). La distinzione è diventata particolarmente importante per lo sviluppo di DNSSEC, che fornisce la prova della non esistenza. [RFC4035], Sezione 3.1.3.2, descrive come i server di nomi autoritativi consapevoli della sicurezza operano questa distinzione, ma nessun RFC esistente descrive il comportamento dei server di nomi ricorsivi.
Questo documento specifica che una risposta NXDOMAIN per un nome di dominio significa che non esiste alcun dominio figlio al di sotto del nome interrogato; inoltre, significa che i resolver DNS dovrebbero interpretare in questo modo la non esistenza memorizzata nella cache. Poiché i nomi di dominio sono organizzati in un albero, è una semplice conseguenza della struttura ad albero: la non esistenza di un nodo implica la non esistenza dell'intero sottoalbero radicato in quel nodo.
1.1. Terminologia
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].
"QNAME": definito in [RFC1034] e in [RFC1035], Sezione 4.1.2, ma, poiché [RFC2308] fornisce una definizione diversa, qui ripetiamo quella originale: il QNAME è il nome di dominio nella sezione della domanda.
"Denied name" (nome negato): il nome di dominio la cui esistenza è stata negata da una risposta con RCODE NXDOMAIN. Nella maggior parte dei casi è il QNAME, ma, a causa di [RFC6604], non è sempre così.
Altri termini sono definiti in [RFC1034], [RFC1035] e (come NXDOMAIN stesso) nel più recente [RFC7719].
Lo spazio dei nomi di dominio è concettualmente definito in termini di una struttura ad albero. L'implementazione di un resolver/cache DNS può utilizzare un albero o altre strutture dati (MAY). Essendo la cache un sottoinsieme dei dati nello spazio dei nomi di dominio, è molto più semplice ragionare su di essa in termini di tale struttura ad albero e descrivere le cose con quei termini (nomi sotto/sopra, nomi discendenti, sottoalberi, ecc.). In effetti, la descrizione dell'algoritmo DNS in [RFC1034] afferma persino l'ipotesi che la cache sia una struttura ad albero, quindi il precedente è già ben stabilito: si veda la sua Sezione 4.3.2, che dice "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache..." Quindi, in questo documento, ogni volta che parliamo di un albero o di operazioni su alberi, ci riferiamo al modello, non all'implementazione effettiva.