Passa al contenuto principale

3. SPAZIO DEI NOMI DI DOMINIO e RECORD DI RISORSE (DOMAIN NAME SPACE and RESOURCE RECORDS)

3.1. Specifiche e terminologia dello spazio dei nomi (Name space specifications and terminology)​

Lo spazio dei nomi di dominio è una struttura ad albero. Ogni nodo e foglia dell'albero corrisponde a un insieme di risorse (che può essere vuoto). Il sistema di dominio non fa distinzioni tra gli usi dei nodi interni e delle foglie, e questo memo utilizza il termine "nodo (node)" per riferirsi a entrambi.

Ogni nodo ha un'etichetta (label), la cui lunghezza varia da zero a 63 ottetti. I nodi fratelli non possono avere la stessa etichetta, sebbene la stessa etichetta possa essere utilizzata per nodi che non sono fratelli. Un'etichetta è riservata, ed è l'etichetta nulla (cioè, di lunghezza zero) utilizzata per la radice.

Il nome di dominio di un nodo è l'elenco delle etichette sul percorso dal nodo alla radice dell'albero. Per convenzione, le etichette che compongono un nome di dominio vengono stampate o lette da sinistra a destra, dal più specifico (più basso, più lontano dalla radice) al meno specifico (più alto, più vicino alla radice).

Rappresentazione interna (Internal representation)​

Internamente, i programmi che manipolano i nomi di dominio dovrebbero rappresentarli come sequenze di etichette, dove ogni etichetta è un ottetto di lunghezza seguito da una stringa di ottetti. Poiché tutti i nomi di dominio terminano alla radice, che ha una stringa nulla come etichetta, queste rappresentazioni interne possono utilizzare un byte di lunghezza zero per terminare un nome di dominio.

Sensibilità alle maiuscole (Case sensitivity)​

Per convenzione, i nomi di dominio possono essere memorizzati con maiuscole e minuscole arbitrarie, ma i confronti dei nomi di dominio per tutte le funzioni di dominio attuali vengono eseguiti in modo case-insensitive, assumendo un set di caratteri ASCII e un bit di ordine superiore zero. Ciò significa che sei libero di creare un nodo con etichetta "A" o un nodo con etichetta "a", ma non entrambi come fratelli; potresti riferirti a entrambi usando "a" o "A". Quando ricevi un nome di dominio o un'etichetta, dovresti preservarne la maiuscola/minuscola. La ragione di questa scelta è che potremmo un giorno aver bisogno di aggiungere nomi di dominio binari completi per nuovi servizi; i servizi esistenti non verrebbero modificati.

Nomi assoluti e relativi (Absolute and relative names)​

Quando un utente deve digitare un nome di dominio, la lunghezza di ogni etichetta viene omessa e le etichette sono separate da punti ("."). Poiché un nome di dominio completo termina con l'etichetta radice, ciò porta a una forma stampata che termina con un punto. Usiamo questa proprietà per distinguere tra:

  • Nomi assoluti (Absolute names): Una stringa di caratteri che rappresenta un nome di dominio completo (spesso chiamato "assoluto"). Ad esempio, "poneria.ISI.EDU."

  • Nomi relativi (Relative names): Una stringa di caratteri che rappresenta le etichette iniziali di un nome di dominio che è incompleto, e dovrebbe essere completato dal software locale utilizzando la conoscenza del dominio locale (spesso chiamato "relativo"). Ad esempio, "poneria" utilizzato nel dominio ISI.EDU.

I nomi relativi vengono presi relativamente a un'origine ben nota, o a un elenco di domini utilizzato come elenco di ricerca. I nomi relativi appaiono principalmente nell'interfaccia utente, dove la loro interpretazione varia da implementazione a implementazione, e nei file master, dove sono relativi a un singolo nome di dominio di origine. L'interpretazione più comune utilizza la radice "." come origine singola o come uno dei membri dell'elenco di ricerca, quindi un nome relativo multi-etichetta è spesso uno in cui il punto finale è stato omesso per risparmiare digitazione.

Limitazioni di lunghezza (Length limitations)​

Per semplificare le implementazioni, il numero totale di ottetti che rappresentano un nome di dominio (cioè, la somma di tutti gli ottetti delle etichette e delle lunghezze delle etichette) è limitato a 255.

Relazioni tra dominio e sottodominio (Domain and subdomain relationships)​

Un dominio è identificato da un nome di dominio e consiste in quella parte dello spazio dei nomi di dominio che si trova al livello o al di sotto del nome di dominio che specifica il dominio. Un dominio è un sottodominio di un altro dominio se è contenuto in quel dominio. Questa relazione può essere testata verificando se il nome del sottodominio termina con il nome del dominio contenitore. Ad esempio, A.B.C.D è un sottodominio di B.C.D, C.D, D e " ".

3.2. Linee guida amministrative sull'uso (Administrative guidelines on use)​

Come questione di politica, le specifiche tecniche del DNS non impongono una particolare struttura ad albero o regole per la selezione delle etichette; il suo obiettivo è essere il più generale possibile, in modo che possa essere utilizzato per costruire applicazioni arbitrarie. In particolare, il sistema è stato progettato in modo che lo spazio dei nomi non dovesse essere organizzato lungo le linee dei confini di rete, dei name server, ecc. La ragione di ciò non è che lo spazio dei nomi non dovrebbe avere una semantica implicita, ma piuttosto che la scelta della semantica implicita dovrebbe essere lasciata aperta per essere utilizzata per il problema in questione, e che diverse parti dell'albero possono avere diverse semantiche implicite. Ad esempio, il dominio IN-ADDR.ARPA è organizzato e distribuito per rete e indirizzo host perché il suo ruolo è tradurre da numeri di rete o host a nomi; i domini NetBIOS [RFC-1001, RFC-1002] sono piatti perché ciò è appropriato per quell'applicazione.

Tuttavia, ci sono alcune linee guida che si applicano alle parti "normali" dello spazio dei nomi utilizzate per host, caselle postali, ecc., che renderanno lo spazio dei nomi più uniforme, forniranno crescita e minimizzeranno i problemi quando il software viene convertito dalla vecchia tabella degli host. Le decisioni politiche sui livelli superiori dell'albero hanno avuto origine in RFC-920. La politica attuale per i livelli superiori è discussa in [RFC-1032]. I problemi di conversione MILNET sono trattati in [RFC-1031].

I domini inferiori che verranno eventualmente suddivisi in più zone dovrebbero fornire ramificazioni nella parte superiore del dominio in modo che la decomposizione eventuale possa essere effettuata senza rinominare. Le etichette dei nodi che utilizzano caratteri speciali, cifre iniziali, ecc., probabilmente romperanno il software più vecchio che dipende da scelte più restrittive.

3.3. Linee guida tecniche sull'uso (Technical guidelines on use)​

Prima che il DNS possa essere utilizzato per contenere informazioni di denominazione per un certo tipo di oggetto, devono essere soddisfatte due esigenze:

  • Una convenzione per la mappatura tra nomi di oggetti e nomi di dominio. Questo descrive come si accede alle informazioni su un oggetto.

  • Tipi di RR e formati di dati per descrivere l'oggetto.

Queste regole possono essere abbastanza semplici o piuttosto complesse. Molto spesso, il progettista deve tenere conto dei formati esistenti e pianificare la compatibilità verso l'alto per l'uso esistente. Possono essere necessarie mappature multiple o livelli di mappatura.

Mappatura del nome host (Host name mapping)​

Per gli host, la mappatura dipende dalla sintassi esistente per i nomi host che è un sottoinsieme della rappresentazione testuale abituale per i nomi di dominio, insieme ai formati RR per descrivere gli indirizzi host, ecc. Poiché abbiamo bisogno di una mappatura inversa affidabile dall'indirizzo al nome host, è anche definita una mappatura speciale per gli indirizzi nel dominio IN-ADDR.ARPA.

Mappatura della casella postale (Mailbox mapping)​

Per le caselle postali, la mappatura è leggermente più complessa. L'indirizzo di posta abituale <local-part>@<mail-domain> viene mappato in un nome di dominio convertendo <local-part> in una singola etichetta (indipendentemente dai punti che contiene), convertendo <mail-domain> in un nome di dominio utilizzando il formato di testo abituale per i nomi di dominio (i punti denotano interruzioni di etichette), e concatenando i due per formare un singolo nome di dominio. Quindi la casella postale [email protected] è rappresentata come nome di dominio da HOSTMASTER.SRI-NIC.ARPA. Un apprezzamento delle ragioni dietro questo design deve anche tenere conto dello schema per gli scambi di posta [RFC-974].

L'utente tipico non è preoccupato di definire queste regole, ma dovrebbe capire che di solito sono il risultato di numerosi compromessi tra i desideri di compatibilità verso l'alto con il vecchio uso, le interazioni tra diverse definizioni di oggetti, e l'impulso inevitabile di aggiungere nuove funzionalità quando si definiscono le regole. Il modo in cui il DNS viene utilizzato per supportare un oggetto è spesso più cruciale delle restrizioni inerenti al DNS.

3.4. Esempio di spazio dei nomi (Example name space)​

La seguente figura mostra una parte dell'attuale spazio dei nomi di dominio, ed è utilizzata in molti esempi in questo RFC. Si noti che l'albero è un sottoinsieme molto piccolo dello spazio dei nomi reale.

                               |
                               |
         +---------------------+------------------+
         |                     |                  |
        MIL                   EDU                ARPA
         |                     |                  |
         |                     |                  |
   +-----+-----+               |     +------+-----+-----+
   |     |     |               |     |      |           |
  BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                               |
   +--------+------------------+---------------+--------+
   |        |                  |               |        |
  UCI      MIT                 |              UDEL     YALE
            |                 ISI
            |                  |
        +---+---+              |
        |       |              |
       LCS  ACHILLES  +--+-----+-----+--------+
        |             |  |     |     |        |
        XX            A  C   VAXA  VENERA Mockapetris

In questo esempio, il dominio radice ha tre sottodomini immediati: MIL, EDU e ARPA. Il dominio LCS.MIT.EDU ha un sottodominio immediato chiamato XX.LCS.MIT.EDU. Tutte le foglie sono anche domini.

3.5. Sintassi del nome preferita (Preferred name syntax)​

Le specifiche DNS tentano di essere il più generali possibile nelle regole per la costruzione dei nomi di dominio. L'idea è che il nome di qualsiasi oggetto esistente possa essere espresso come nome di dominio con modifiche minime. Tuttavia, quando si assegna un nome di dominio a un oggetto, l'utente prudente selezionerà un nome che soddisfi sia le regole del sistema di dominio sia qualsiasi regola esistente per l'oggetto, sia che queste regole siano pubblicate o implicite dai programmi esistenti.

Ad esempio, quando si nomina un dominio di posta, l'utente dovrebbe soddisfare sia le regole di questo memo sia quelle in RFC-822. Quando si crea un nuovo nome host, dovrebbero essere seguite le vecchie regole per HOSTS.TXT. Ciò evita problemi quando il vecchio software viene convertito per utilizzare i nomi di dominio.

La seguente sintassi produrrà meno problemi con molte applicazioni che utilizzano nomi di dominio (ad esempio, posta, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= uno qualsiasi dei 52 caratteri alfabetici da A a Z in
             maiuscolo e da a a z in minuscolo

<digit> ::= una qualsiasi delle dieci cifre da 0 a 9

Si noti che sebbene le lettere maiuscole e minuscole siano consentite nei nomi di dominio, nessuna importanza è attribuita alla maiuscola/minuscola. Cioè, due nomi con la stessa ortografia ma maiuscola/minuscola diversa devono essere trattati come identici.

Le etichette devono seguire le regole per i nomi host ARPANET. Devono iniziare con una lettera, terminare con una lettera o una cifra, e avere come caratteri interni solo lettere, cifre e trattini. Ci sono anche alcune restrizioni sulla lunghezza. Le etichette devono essere di 63 caratteri o meno.

Ad esempio, le seguenti stringhe identificano host in Internet:

A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA

3.6. Record di risorse (Resource Records)​

Un nome di dominio identifica un nodo. Ogni nodo ha un insieme di informazioni di risorsa, che può essere vuoto. L'insieme di informazioni di risorsa associate a un nome particolare è composto da record di risorse (RR) separati. L'ordine degli RR in un insieme non è significativo e non deve essere preservato dai name server, dai resolver o da altre parti del DNS.

Quando parliamo di un RR specifico, assumiamo che abbia quanto segue:

owner (proprietario)​

Che è il nome di dominio dove si trova l'RR.

type (tipo)​

Che è un valore codificato a 16 bit che specifica il tipo della risorsa in questo record di risorsa. I tipi si riferiscono a risorse astratte.

Questo memo utilizza i seguenti tipi:

  • A: un indirizzo host
  • CNAME: identifica il nome canonico di un alias
  • HINFO: identifica la CPU e l'OS utilizzati da un host
  • MX: identifica uno scambio di posta per il dominio. Vedere [RFC-974] per i dettagli.
  • NS: il name server autorevole per il dominio
  • PTR: un puntatore a un'altra parte dello spazio dei nomi di dominio
  • SOA: identifica l'inizio di una zona di autorità

class (classe)​

Che è un valore codificato a 16 bit che identifica una famiglia di protocolli o un'istanza di un protocollo.

Questo memo utilizza le seguenti classi:

  • IN: il sistema Internet
  • CH: il sistema Chaos

TTL​

Che è il tempo di vita dell'RR. Questo campo è un intero a 32 bit in unità di secondi, ed è utilizzato principalmente dai resolver quando mettono in cache gli RR. Il TTL descrive per quanto tempo un RR può essere memorizzato nella cache prima che debba essere scartato.

RDATA​

Che sono i dati dipendenti dal tipo e talvolta dalla classe che descrivono la risorsa:

  • A: Per la classe IN, un indirizzo IP a 32 bit. Per la classe CH, un nome di dominio seguito da un indirizzo Chaos ottale a 16 bit.
  • CNAME: un nome di dominio.
  • MX: un valore di preferenza a 16 bit (più basso è migliore) seguito da un nome host disposto ad agire come scambio di posta per il dominio proprietario.
  • NS: un nome host.
  • PTR: un nome di dominio.
  • SOA: diversi campi.

Considerazioni sulla struttura degli RR (RR structure considerations)​

Il nome del proprietario è spesso implicito, piuttosto che formare una parte integrale dell'RR. Ad esempio, molti name server formano internamente strutture ad albero o hash per lo spazio dei nomi, e concatenano gli RR dai nodi. Le parti RR rimanenti sono l'intestazione fissa (tipo, classe, TTL) che è coerente per tutti gli RR, e una parte variabile (RDATA) che si adatta alle esigenze della risorsa descritta.

Il significato del campo TTL è un limite di tempo su quanto a lungo un RR può essere mantenuto in una cache. Questo limite non si applica ai dati autorevoli nelle zone; è anche temporizzato, ma dalle politiche di aggiornamento per la zona. Il TTL è assegnato dall'amministratore per la zona da cui provengono i dati. Sebbene i TTL brevi possano essere utilizzati per minimizzare la memorizzazione nella cache, e un TTL zero proibisce la memorizzazione nella cache, le realtà delle prestazioni Internet suggeriscono che questi tempi dovrebbero essere dell'ordine di giorni per l'host tipico. Se un cambiamento può essere anticipato, il TTL può essere ridotto prima del cambiamento per minimizzare l'incoerenza durante il cambiamento, e quindi aumentato di nuovo al suo valore precedente dopo il cambiamento.

I dati nella sezione RDATA degli RR sono trasportati come una combinazione di stringhe binarie e nomi di dominio. I nomi di dominio sono frequentemente utilizzati come "puntatori" ad altri dati nel DNS.

3.6.1. Espressione testuale degli RR (Textual expression of RRs)​

Gli RR sono rappresentati in forma binaria nei pacchetti del protocollo DNS, e sono solitamente rappresentati in forma altamente codificata quando memorizzati in un name server o resolver. In questo memo, adottiamo uno stile simile a quello utilizzato nei file master per mostrare il contenuto degli RR. In questo formato, la maggior parte degli RR viene mostrata su una singola riga, sebbene le linee di continuazione siano possibili utilizzando le parentesi.

L'inizio della riga fornisce il proprietario dell'RR. Se una riga inizia con uno spazio vuoto, si assume che il proprietario sia lo stesso di quello dell'RR precedente. Le righe vuote sono spesso incluse per leggibilità.

Dopo il proprietario, elenchiamo il TTL, il tipo e la classe dell'RR. La classe e il tipo utilizzano i mnemonici definiti sopra, e il TTL è un intero prima del campo tipo. Per evitare ambiguità nell'analisi, i mnemonici di tipo e classe sono disgiunti, i TTL sono interi, e il mnemonico di tipo è sempre l'ultimo. La classe IN e i valori TTL sono spesso omessi dagli esempi nell'interesse della chiarezza.

La sezione dati di risorsa o RDATA dell'RR viene fornita utilizzando la conoscenza della rappresentazione tipica dei dati.

Ad esempio, potremmo mostrare gli RR trasportati in un messaggio come:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A       128.9.0.32
                A       10.1.0.52
VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33

Gli RR MX hanno una sezione RDATA che consiste in un numero a 16 bit seguito da un nome di dominio. Gli RR di indirizzo utilizzano un formato di indirizzo IP standard per contenere un indirizzo Internet a 32 bit.

Questo esempio mostra sei RR, con due RR in ciascuno dei tre nomi di dominio.

Allo stesso modo potremmo vedere:

XX.LCS.MIT.EDU. IN      A       10.0.0.44
                CH      A       MIT.EDU. 2420

Questo esempio mostra due indirizzi per XX.LCS.MIT.EDU, ciascuno di una classe diversa.

3.6.2. Alias e nomi canonici (Aliases and canonical names)​

Nei sistemi esistenti, gli host e altre risorse hanno spesso diversi nomi che identificano la stessa risorsa. Ad esempio, i nomi C.ISI.EDU e USC-ISIC.ARPA identificano entrambi lo stesso host. Allo stesso modo, nel caso delle caselle postali, molte organizzazioni forniscono molti nomi che vanno effettivamente alla stessa casella postale; ad esempio [email protected], [email protected] e [email protected] vanno tutti alla stessa casella postale (sebbene il meccanismo dietro questo sia alquanto complicato).

La maggior parte di questi sistemi ha una nozione che uno dell'insieme equivalente di nomi è il nome canonico o primario e tutti gli altri sono alias.

Record CNAME (CNAME records)​

Il sistema di dominio fornisce tale funzionalità utilizzando il record di nome canonico (CNAME) RR. Un RR CNAME identifica il suo nome proprietario come alias, e specifica il nome canonico corrispondente nella sezione RDATA dell'RR. Se un RR CNAME è presente in un nodo, nessun altro dato dovrebbe essere presente; ciò garantisce che i dati per un nome canonico e i suoi alias non possano essere diversi. Questa regola garantisce anche che un CNAME memorizzato nella cache possa essere utilizzato senza controllare con un server autorevole altri tipi di RR.

Gli RR CNAME causano azioni speciali nel software DNS. Quando un name server non riesce a trovare un RR desiderato nell'insieme di risorse associato al nome di dominio, controlla se l'insieme di risorse consiste in un record CNAME con una classe corrispondente. Se così è, il name server include il record CNAME nella risposta e riavvia la query al nome di dominio specificato nel campo dati del record CNAME. L'unica eccezione a questa regola è che le query che corrispondono al tipo CNAME non vengono riavviate.

Ad esempio, supponiamo che un name server stesse elaborando una query per USC-ISIC.ARPA, richiedendo informazioni di tipo A, e avesse i seguenti record di risorse:

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

Entrambi questi RR verrebbero restituiti nella risposta alla query di tipo A, mentre una query di tipo CNAME o * dovrebbe restituire solo il CNAME.

I nomi di dominio negli RR che puntano a un altro nome dovrebbero sempre puntare al nome primario e non all'alias. Ciò evita indirezioni extra nell'accesso alle informazioni. Ad esempio, l'RR da indirizzo a nome per l'host sopra dovrebbe essere:

52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

piuttosto che puntare a USC-ISIC.ARPA. Naturalmente, secondo il principio di robustezza, il software di dominio non dovrebbe fallire quando presentato con catene o cicli CNAME; le catene CNAME dovrebbero essere seguite e i cicli CNAME segnalati come errore.

3.7. Query (Queries)​

Le query sono messaggi che possono essere inviati a un name server per provocare una risposta. In Internet, le query sono trasportate in datagrammi UDP o su connessioni TCP. La risposta del name server risponde alla domanda posta nella query, riferisce il richiedente a un altro insieme di name server, o segnala una condizione di errore.

In generale, l'utente non genera query direttamente, ma effettua invece una richiesta a un resolver che a sua volta invia una o più query ai name server e gestisce le condizioni di errore e i riferimenti che possono risultarne. Naturalmente, le possibili domande che possono essere poste in una query plasmano il tipo di servizio che un resolver può fornire.

Formato del messaggio (Message format)​

Le query e le risposte DNS sono trasportate in un formato di messaggio standard. Il formato del messaggio ha un'intestazione contenente un numero di campi fissi che sono sempre presenti, e quattro sezioni che trasportano parametri di query e RR.

Il campo più importante nell'intestazione è un campo di quattro bit chiamato opcode che separa diverse query. Dei possibili 16 valori, uno (query standard) fa parte del protocollo ufficiale, due (query inversa e query di stato) sono opzioni, uno (completamento) è obsoleto, e il resto non è assegnato.

Le quattro sezioni sono:

  • Question (Domanda): Trasporta il nome della query e altri parametri di query.
  • Answer (Risposta): Trasporta gli RR che rispondono direttamente alla query.
  • Authority (Autorità): Trasporta gli RR che descrivono altri server autorevoli. Può opzionalmente trasportare l'RR SOA per i dati autorevoli nella sezione risposta.
  • Additional (Aggiuntivo): Trasporta gli RR che possono essere utili nell'utilizzare gli RR nelle altre sezioni.

Si noti che il contenuto, ma non il formato, di queste sezioni varia con l'opcode dell'intestazione.

3.7.1. Query standard (Standard queries)​

Una query standard specifica un nome di dominio di destinazione (QNAME), un tipo di query (QTYPE) e una classe di query (QCLASS) e richiede gli RR che corrispondono. Questo tipo di query costituisce una così vasta maggioranza delle query DNS che utilizziamo il termine "query" per indicare query standard se non diversamente specificato. I campi QTYPE e QCLASS sono ciascuno di 16 bit di lunghezza, e sono un sovrainsieme dei tipi e delle classi definiti.

Il campo QTYPE può contenere:

  • <qualsiasi tipo>: corrisponde solo a quel tipo. (ad esempio, A, PTR).
  • AXFR: QTYPE speciale di trasferimento di zona.
  • MAILB: corrisponde a tutti gli RR relativi alle caselle postali (ad esempio MB e MG).
  • *: corrisponde a tutti i tipi di RR.

Il campo QCLASS può contenere:

  • <qualsiasi classe>: corrisponde solo a quella classe (ad esempio, IN, CH).
  • *: corrisponde a tutte le classi di RR.

Utilizzando il nome di dominio della query, QTYPE e QCLASS, il name server cerca gli RR corrispondenti. Oltre ai record pertinenti, il name server può restituire RR che puntano a un name server che ha le informazioni desiderate o RR che ci si aspetta siano utili nell'interpretare gli RR pertinenti. Ad esempio, un name server che non ha le informazioni richieste può conoscere un name server che le ha; un name server che restituisce un nome di dominio in un RR pertinente può anche restituire l'RR che lega quel nome di dominio a un indirizzo.

Esempio di query e risposta (Example query and response)​

Ad esempio, un programma di posta che cerca di inviare posta a [email protected] potrebbe chiedere al resolver informazioni di posta su ISI.EDU, risultando in una query per QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. La sezione risposta della risposta sarebbe:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.

mentre la sezione aggiuntiva potrebbe essere:

VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33
VENERA.ISI.EDU. A       10.1.0.52
                A       128.9.0.32

Perché il server presume che se il richiedente vuole informazioni di scambio di posta, probabilmente vorrà gli indirizzi degli scambi di posta poco dopo.

Si noti che la costruzione QCLASS=* richiede un'interpretazione speciale riguardo all'autorità. Poiché un particolare name server potrebbe non conoscere tutte le classi disponibili nel sistema di dominio, non può mai sapere se è autorevole per tutte le classi. Pertanto, le risposte alle query QCLASS=* non possono mai essere autorevoli.

3.7.2. Query inverse (Inverse queries) (Opzionale)​

I name server possono anche supportare query inverse che mappano una particolare risorsa a un nome di dominio o nomi di dominio che hanno quella risorsa. Ad esempio, mentre una query standard potrebbe mappare un nome di dominio a un RR SOA, la corrispondente query inversa potrebbe mappare l'RR SOA al nome di dominio.

L'implementazione di questo servizio è opzionale in un name server, ma tutti i name server devono almeno essere in grado di comprendere un messaggio di query inversa e restituire una risposta di errore non implementata.

Il sistema di dominio non può garantire la completezza o l'unicità delle query inverse perché il sistema di dominio è organizzato per nome di dominio piuttosto che per indirizzo host o qualsiasi altro tipo di risorsa. Le query inverse sono principalmente utili per attività di debug e manutenzione del database.

Le query inverse potrebbero non restituire il TTL appropriato e non indicano i casi in cui l'RR identificato è uno di un insieme (ad esempio, un indirizzo per un host che ha più indirizzi). Pertanto, gli RR restituiti nelle query inverse non dovrebbero mai essere memorizzati nella cache.

Le query inverse NON sono un metodo accettabile per mappare gli indirizzi host ai nomi host; utilizzare invece il dominio IN-ADDR.ARPA.

Una discussione dettagliata delle query inverse è contenuta in [RFC-1035].

3.8. Query di stato (Status queries) (Sperimentale)​

Da definire.

3.9. Query di completamento (Completion queries) (Obsoleto)​

I servizi di completamento opzionali descritti negli RFC 882 e 883 sono stati eliminati. Servizi riprogettati potrebbero diventare disponibili in futuro, o gli opcode potrebbero essere recuperati per altro uso.

Ultimo aggiornamento il