5. Resource Record Sets (Insiemi di record di risorse)
Ogni record di risorsa DNS (Resource Record, RR) ha un'etichetta (label), una classe (class), un tipo (type) e dati (data). Non ha senso che due record abbiano etichetta, classe, tipo e dati tutti uguali — i server dovrebbero sopprimere tali duplicati quando li incontrano. È tuttavia possibile per la maggior parte dei tipi di record esistere con la stessa etichetta, classe e tipo, ma con dati diversi. Un tale gruppo di record è definito qui come un insieme di record di risorse (Resource Record Set, RRSet).
5.1. Sending RRs from an RRSet (Invio di RR da un RRSet)
Una query per un'etichetta, classe e tipo specifici (o non specifici) restituirà sempre tutti i record nell'RRSet associato — che si tratti di uno o più RR. La risposta deve essere contrassegnata come "troncata" (truncated) se l'intero RRSet non può essere contenuto nella risposta.
5.2. TTLs of RRs in an RRSet (TTL di RR in un RRSet)
I record di risorse hanno anche un tempo di vita (Time to Live, TTL). È possibile che i RR in un RRSet abbiano TTL diversi. Non sono stati trovati usi per questo che non possano essere meglio realizzati in altri modi. Questo può tuttavia causare risposte parziali (non contrassegnate come "troncate") da un server di cache, dove i TTL per alcuni ma non tutti i RR nell'RRSet sono scaduti.
Di conseguenza, l'uso di TTL diversi in un RRSet è ora deprecato, i TTL di tutti i RR in un RRSet devono essere gli stessi.
Se un client riceve una risposta contenente RR da un RRSet con TTL diversi, dovrebbe trattare questo come un errore. Se l'RRSet interessato proviene da una fonte non autoritativa per questi dati, il client dovrebbe semplicemente ignorare l'RRSet e, se i valori erano necessari, cercare di acquisirli da una fonte autoritativa. I client configurati per inviare tutte le query a uno o più server particolari dovrebbero trattare quei server come autoritativi per questo scopo. Se una fonte autoritativa invia un tale RRSet malformato, il client dovrebbe trattare i RR per tutti gli scopi come se tutti i TTL nell'RRSet fossero stati impostati sul valore del TTL più basso nell'RRSet. In nessun caso un server può inviare un RRSet con TTL non tutti uguali.
5.3. DNSSEC Special Cases (Casi speciali DNSSEC)
Due dei tipi di record aggiunti dalla sicurezza DNS (DNSSEC) [RFC2065] richiedono particolare attenzione quando si considera la formazione degli insiemi di record di risorse. Questi sono i record SIG e NXT. Va notato che la sicurezza DNS è ancora molto nuova e c'è, fino ad ora, poca esperienza con essa. I lettori dovrebbero essere preparati al fatto che le informazioni relative a DNSSEC contenute in questo documento diventino obsolete man mano che la specifica di sicurezza DNS matura.
5.3.1. SIG records and RRSets (Record SIG e RRSets)
Un record SIG fornisce dati di firma (validazione) per un altro RRSet nel DNS. Quando una zona è stata firmata, ogni RRSet nella zona avrà un record SIG associato. Il tipo di dati dell'RRSet è incluso nei dati del SIG RR per indicare con quale particolare RRSet questo record SIG è associato. Se le regole di cui sopra fossero applicate, ogni volta che un record SIG fosse incluso con una risposta per validare quella risposta, anche i record SIG per tutti gli altri RRSet associati al nodo appropriato dovrebbero essere inclusi. In alcuni casi, questo potrebbe essere un numero molto grande di record, il fatto che siano RR piuttosto grandi non aiuta.
Pertanto, è specificamente consentito che la sezione di autorità contenga solo quei SIG RR con il campo "tipo coperto" (type covered) uguale al campo tipo di una risposta restituita. Tuttavia, quando i record SIG vengono restituiti nella sezione di risposta, in risposta a una query per record SIG o una query per tutti i record associati a un nome (type=ANY), l'intero SIG RRSet deve essere incluso, come per qualsiasi altro tipo di RR.
I server che ricevono risposte contenenti record SIG nella sezione di autorità, o (probabilmente in modo errato) come dati aggiuntivi, devono comprendere che l'intero RRSet quasi certamente non è stato incluso. Pertanto, non devono memorizzare nella cache quel record SIG in un modo che permetterebbe di restituirlo se una query per record SIG fosse ricevuta presso quel server. RFC2065 richiede effettivamente che le query SIG siano dirette solo a server autoritativi per evitare i problemi che potrebbero essere causati qui, e finché esistono server che non comprendono le proprietà speciali dei record SIG, questo rimarrà necessario. Tuttavia, un'attenta progettazione dell'elaborazione dei record SIG nelle nuove implementazioni dovrebbe permettere di rilassare questa restrizione in futuro, in modo che i resolver non debbano trattare le query di record SIG in modo speciale.
5.3.2. NXT RRs (Record NXT)
I record di risorsa successivi (Next Resource Records, NXT) sono ancora più peculiari. Ci sarà sempre un solo record NXT in una zona per una particolare etichetta, quindi superficialmente il problema dell'RRSet è banale. Tuttavia, a un taglio di zona, sia la zona padre che la zona figlia (superzona e subzona nella terminologia RFC2065) avranno record NXT per lo stesso nome. Quei due record NXT non formano un RRSet, anche quando entrambe le zone sono ospitate sullo stesso server. Gli NXT RRSet contengono sempre solo un singolo RR. Dove entrambi i record NXT sono visibili, esistono due RRSet. Tuttavia, i server non sono tenuti a trattare questo come un caso speciale quando ricevono record NXT in una risposta. Possono scegliere di notare l'esistenza di due diversi NXT RRSet e trattarli come farebbero con due diversi RRSet di qualsiasi altro tipo. Cioè, memorizzare nella cache uno e ignorare l'altro. I server consapevoli della sicurezza dovranno elaborare correttamente il record NXT nella risposta ricevuta.
5.4. Receiving RRSets (Ricezione degli RRSets)
I server non devono mai unire RR da una risposta con RR nella loro cache per formare un RRSet. Se una risposta contiene dati che formerebbero un RRSet con dati nella cache di un server, il server deve ignorare i RR nella risposta o scartare l'intero RRSet attualmente nella cache, a seconda dei casi. Di conseguenza, il problema della variazione dei TTL tra la cache e una risposta non causa preoccupazione, uno verrà ignorato. Cioè, uno dei set di dati è sempre errato se i dati da una risposta differiscono dai dati nella cache. La sfida per il server è determinare quale dei set di dati è corretto, se presente, e mantenere quello ignorando l'altro. Si noti che se un server riceve una risposta contenente un RRSet identico a quello nella sua cache, con la possibile eccezione del valore TTL, può, opzionalmente, aggiornare il TTL nella sua cache con il TTL della risposta ricevuta. Dovrebbe farlo se la risposta ricevuta fosse considerata più autoritativa (come discusso nella sezione successiva) rispetto alla risposta precedentemente memorizzata nella cache.
5.4.1. Ranking data (Classificazione dei dati)
Nel considerare se accettare un RRSet in una risposta, o mantenere un RRSet già nella sua cache, un server dovrebbe considerare la relativa probabile affidabilità dei vari dati. Una risposta autoritativa da una risposta dovrebbe sostituire i dati memorizzati nella cache che erano stati ottenuti da informazioni aggiuntive in una risposta precedente. Tuttavia, le informazioni aggiuntive da una risposta verranno ignorate se la cache contiene dati da una risposta autoritativa o da un file di zona.
L'accuratezza dei dati disponibili è presunta dalla sua fonte. L'affidabilità deve essere, in ordine dal più al meno:
- Dati da un file di zona primaria, diversi dai dati glue
- Dati da un trasferimento di zona, diverso dal glue
- I dati autoritativi inclusi nella sezione di risposta di una risposta autoritativa
- Dati dalla sezione di autorità di una risposta autoritativa
- Glue da una zona primaria, o glue da un trasferimento di zona
- Dati dalla sezione di risposta di una risposta non autoritativa, e dati non autoritativi dalla sezione di risposta di risposte autoritativ
- Informazioni aggiuntive da una risposta autoritativa
- Dati dalla sezione di autorità di una risposta non autoritativa
- Informazioni aggiuntive da risposte non autoritativ
Si noti che la sezione di risposta di una risposta autoritativa normalmente contiene solo dati autoritativi. Tuttavia, quando il nome cercato è un alias (vedere la sezione 10.1.1), solo il record che descrive quell'alias è necessariamente autoritativo. I client dovrebbero presumere che altri record potrebbero provenire dalla cache del server. Quando sono richieste risposte autoritativ, il client dovrebbe interrogare nuovamente, utilizzando il nome canonico associato all'alias.
I RR non autenticati ricevuti e memorizzati nella cache dal gruppo meno affidabile, cioè i dati dalla sezione di dati aggiuntivi e i dati dalla sezione di autorità di una risposta non autoritativa, non dovrebbero essere memorizzati nella cache in modo tale da consentire loro di essere restituiti come risposte a una query ricevuta. Possono essere restituiti come informazioni aggiuntive dove appropriato. Ignorare questo permetterebbe all'affidabilità di dati relativamente inaffidabili di essere aumentata senza causa o scusa.
Quando viene utilizzata la sicurezza DNS [RFC2065] e una risposta autenticata è stata ricevuta e verificata, i dati così autenticati devono essere considerati più affidabili dei dati non autenticati dello stesso tipo. Si noti che in tutto questo documento, "autoritativo" (authoritative) significa una risposta con il bit AA impostato. DNSSEC utilizza catene fidate di record SIG e KEY per determinare l'autenticità dei dati, il bit AA è quasi irrilevante. Tuttavia, i server consapevoli di DNSSEC devono ancora impostare correttamente il bit AA nelle risposte per consentire il corretto funzionamento con server che non sono consapevoli della sicurezza (quasi tutti attualmente).
Si noti che, escluso il glue, è impossibile che dati provenienti da due file di zona primaria configurati correttamente, due zone secondarie configurate correttamente (dati da trasferimenti di zona) o dati da zone primarie e secondarie configurate correttamente entrino mai in conflitto. Dove esiste glue per lo stesso nome in più zone e differisce nel valore, il nameserver dovrebbe selezionare i dati da un file di zona primaria in preferenza a una secondaria, ma altrimenti può scegliere qualsiasi singolo set di tali dati. Scegliere quello che sembra provenire da una fonte più vicina alla fonte di dati autoritativa può avere senso dove questo può essere determinato. Scegliere i dati primari rispetto ai secondari consente di scoprire più facilmente la fonte di dati glue errati quando esiste un problema con tali dati. Quando un server può rilevare da due file di zona che uno o più sono configurati in modo errato, in modo da creare conflitti, dovrebbe rifiutare di caricare le zone determinate erronee ed emettere diagnostiche appropriate.
Il "Glue" di cui sopra include qualsiasi record in un file di zona che non fa propriamente parte di quella zona, inclusi i record di nameserver di sottozone delegate (record NS), i record di indirizzo che accompagnano quei record NS (A, AAAA, ecc.), e qualsiasi altro dato disperso che potrebbe apparire.
5.5. Sending RRSets (reprise) (Invio degli RRSets (ripresa))
Un insieme di record di risorse dovrebbe essere incluso solo una volta in qualsiasi risposta DNS. Può apparire in una qualsiasi delle sezioni Risposta, Autorità o Informazioni aggiuntive, secondo necessità. Tuttavia, non dovrebbe essere ripetuto nella stessa o in qualsiasi altra sezione, tranne quando esplicitamente richiesto da una specifica. Ad esempio, una risposta AXFR richiede che il record SOA (sempre un RRSet contenente un singolo RR) sia sia il primo che l'ultimo record della risposta. Dove i duplicati sono richiesti in questo modo, il TTL trasmesso in ogni caso deve essere lo stesso.