Passa al contenuto principale

5. Insiemi di record di risorsa

Ogni record di risorsa DNS (RR) ha un'etichetta, una classe, un tipo e dei dati. È privo di significato che due record abbiano etichetta, classe, tipo e dati tutti uguali - i server dovrebbero sopprimere tali duplicati se li incontrano. È tuttavia possibile che la maggior parte dei tipi di record esista con la stessa etichetta, classe e tipo, ma con dati diversi. Un tale gruppo di record è con la presente definito un insieme di record di risorsa (RRSet).

5.1. Invio di RR da un RRSet​

Una query per un'etichetta, una classe e un 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" se l'intero RRSet non entra nella risposta.

5.2. TTL degli RR in un RRSet​

I record di risorsa hanno anche un tempo di vita (TTL). È possibile che gli RR di un RRSet abbiano TTL differenti. Non sono stati trovati usi per questo che non possano essere realizzati meglio in altri modi. Ciò può tuttavia causare risposte parziali (non contrassegnate come "troncate") da un server con cache, quando i TTL di alcuni ma non di tutti gli RR dell'RRSet sono scaduti.

Di conseguenza l'uso di TTL differenti in un RRSet è con la presente deprecato; i TTL di tutti gli RR di un RRSet devono essere uguali.

Se un client riceve una risposta contenente RR di un RRSet con TTL differenti, dovrebbe trattarla come un errore. Se l'RRSet in questione proviene da una fonte non autoritativa per questi dati, il client dovrebbe semplicemente ignorare l'RRSet e, se i valori fossero necessari, cercare di ottenerli da una fonte autoritativa. I client configurati per inviare tutte le query a uno o più server particolari dovrebbero trattare quei server come autoritativi a questo scopo. Se una fonte autoritativa invia un RRSet così malformato, il client dovrebbe trattare gli RR, a tutti gli effetti, come se tutti i TTL dell'RRSet fossero stati impostati al valore del TTL più basso dell'RRSet. In nessun caso un server può inviare un RRSet con TTL non tutti uguali.

5.3. 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 risorsa. Si tratta dei record SIG e NXT. Va notato che la Sicurezza DNS è ancora molto nuova e che, finora, c'è poca esperienza al riguardo. I lettori dovrebbero essere preparati al fatto che le informazioni relative a DNSSEC contenute in questo documento diventeranno obsolete man mano che la specifica di Sicurezza DNS matura.

5.3.1. Record SIG e RRSet​

Un record SIG fornisce dati di firma (validazione) per un altro RRSet nel DNS. Dove una zona è stata firmata, ogni RRSet della zona avrà avuto associato un record SIG. Il tipo di dati dell'RRSet è incluso nei dati del RR SIG, per indicare a quale particolare RRSet questo record SIG è associato. Se le regole di cui sopra fossero applicate, ogni volta che un record SIG fosse incluso in una risposta per validare quella risposta, si dovrebbero includere anche i record SIG per tutti gli altri RRSet associati al nodo appropriato. In alcuni casi, ciò potrebbe comportare un numero molto elevato di record, aggravato dal fatto che si tratta di RR piuttosto grandi.

Pertanto, è specificamente consentito che la sezione di autorità (authority section) contenga solo quei RR SIG con il campo "type covered" uguale al campo tipo di una risposta restituita. Tuttavia, dove i record SIG sono restituiti nella sezione di risposta (answer section), in risposta a una query per record SIG, o a una query per tutti i record associati a un nome (type=ANY), l'intero RRSet SIG 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 quel record SIG in cache in modo tale da consentirne la restituzione qualora a quel server pervenga una query per record SIG. RFC2065 richiede in realtà che le query SIG siano indirizzate solo a server autoritativi per evitare i problemi che si potrebbero causare in questo caso, e finché esistono server che non comprendono le proprietà speciali dei record SIG, ciò resterà necessario. Tuttavia, una progettazione accurata dell'elaborazione dei record SIG nelle nuove implementazioni dovrebbe consentire di allentare questa restrizione in futuro, così che i resolver non debbano trattare in modo speciale le query per record SIG.

È stato occasionalmente affermato che una richiesta ricevuta per un record SIG dovrebbe essere inoltrata a un server autoritativo, anziché essere soddisfatta con i dati presenti nella cache. Ciò non è necessario - un server che conosce il caso speciale di SIG per elaborarlo in questo modo farebbe meglio a memorizzare correttamente in cache i record SIG, tenendo conto delle loro caratteristiche. Allora il server può determinare quando è sicuro rispondere dalla cache e quando la risposta non è disponibile e la query deve essere inoltrata.

5.3.2. RR NXT​

I record Next Resource (NXT) sono ancora più peculiari. In una zona esisterà sempre e solo un record NXT per una particolare etichetta, quindi superficialmente il problema dell'RRSet è banale. Tuttavia, a un taglio di zona, sia la zona padre sia 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 RRSet NXT contengono sempre un solo 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 RRSet NXT e trattarla come tratterebbero due diversi RRSet di qualsiasi altro tipo. Vale a dire, memorizzarne uno in cache e ignorare l'altro. I server consapevoli della sicurezza dovranno comunque elaborare correttamente il record NXT nella risposta ricevuta.

5.4. Ricezione di RRSet​

I server non devono mai fondere gli RR di una risposta con gli RR della propria cache per formare un RRSet. Se una risposta contiene dati che formerebbero un RRSet con i dati nella cache di un server, il server deve, a seconda dei casi, ignorare gli RR della risposta oppure scartare l'intero RRSet attualmente presente nella cache. Di conseguenza il problema dei TTL che variano tra la cache e una risposta non desta preoccupazione, uno dei due verrà ignorato. Vale a dire, uno degli insiemi di dati è sempre errato se i dati di una risposta differiscono dai dati nella cache. La sfida per il server è determinare quale degli insiemi di dati sia corretto, se uno lo è, e conservarlo, ignorando l'altro. Si noti che se un server riceve una risposta contenente un RRSet identico a quello nella propria cache, con la possibile eccezione del valore TTL, può, facoltativamente, aggiornare il TTL nella propria cache con il TTL della risposta ricevuta. Dovrebbe farlo se la risposta ricevuta fosse considerata più autoritativa (come discusso nella sezione successiva) della risposta precedentemente memorizzata in cache.

5.4.1. Classificazione dei dati​

Quando considera se accettare un RRSet in una replica, o conservare invece un RRSet già presente nella propria cache, un server dovrebbe considerare la relativa probabile affidabilità dei vari dati. Una risposta autoritativa contenuta in una replica dovrebbe sostituire i dati in cache che erano stati ottenuti da informazioni aggiuntive in una replica precedente. Tuttavia le informazioni aggiuntive provenienti da una replica saranno ignorate se la cache contiene dati provenienti da una risposta autoritativa o da un file di zona.

L'accuratezza dei dati disponibili è presunta dalla loro fonte. L'affidabilità sarà, in ordine dal più al meno:

  • Dati provenienti da un file di zona primario, diversi dai dati glue,
  • Dati provenienti da un trasferimento di zona, diversi dal glue,
  • I dati autoritativi inclusi nella sezione di risposta di una risposta autoritativa.
  • Dati provenienti dalla sezione di autorità di una risposta autoritativa,
  • Glue proveniente da una zona primaria, o glue proveniente da un trasferimento di zona,
  • Dati provenienti dalla sezione di risposta di una risposta non autoritativa, e dati non autoritativi provenienti dalla sezione di risposta di risposte autoritative,
  • Informazioni aggiuntive provenienti da una risposta autoritativa, Dati provenienti dalla sezione di autorità di una risposta non autoritativa, Informazioni aggiuntive provenienti da risposte non autoritative.

Si noti che la sezione di risposta di una risposta autoritativa contiene normalmente 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 possano provenire dalla cache del server. Dove sono richieste risposte autoritative, il client dovrebbe interrogare di nuovo, usando il nome canonico associato all'alias.

Gli RR non autenticati ricevuti e memorizzati in cache dal meno affidabile di quei raggruppamenti, vale a dire i dati provenienti dalla sezione dei dati aggiuntivi e i dati provenienti dalla sezione di autorità di una risposta non autoritativa, non dovrebbero essere memorizzati in cache in modo tale da poter essere mai restituiti come risposte a una query ricevuta. Possono essere restituiti come informazioni aggiuntive dove appropriato. Ignorare ciò consentirebbe di aumentare senza causa o giustificazione l'affidabilità di dati relativamente inaffidabili.

Quando è in uso la sicurezza DNS [RFC2065], e una replica autenticata è stata ricevuta e verificata, i dati così autenticati saranno considerati più affidabili dei dati non autenticati dello stesso tipo. Si noti che in tutto questo documento "authoritative" significa una replica con il bit AA impostato. DNSSEC usa 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 comunque impostare correttamente il bit AA nelle risposte per consentire un funzionamento corretto con server che non sono consapevoli della sicurezza (quasi tutti attualmente).

Si noti che, escluso il glue, è impossibile che i dati di due file di zona primari configurati correttamente, di due zone secondarie configurate correttamente (dati provenienti da trasferimenti di zona) o i dati di zone primarie e secondarie configurate correttamente entrino mai in conflitto. Dove il glue per lo stesso nome esiste in più zone e differisce nel valore, il nameserver dovrebbe selezionare i dati di un file di zona primario preferendoli a quelli secondari, ma per il resto può scegliere qualsiasi singolo insieme di tali dati. Scegliere quello che sembra provenire da una fonte più vicina alla fonte dei dati autoritativi può avere senso dove ciò può essere determinato. Scegliere i dati primari rispetto ai secondari consente di individuare più prontamente la fonte di dati glue errati, quando esiste un problema con tali dati. Dove un server può rilevare da due file di zona che uno o più sono configurati in modo errato, così da creare conflitti, dovrebbe rifiutarsi di caricare le zone determinate come erronee e emettere diagnostiche appropriate.

Il "glue" di cui sopra comprende qualsiasi record in un file di zona che non faccia propriamente parte di quella zona, inclusi i record nameserver delle sottozone delegate (record NS), i record di indirizzo che accompagnano quei record NS (A, AAAA, ecc.), e qualsiasi altro dato estraneo che possa comparire.

5.5. Invio di RRSet (ripresa)​

Un insieme di record di risorsa dovrebbe essere incluso una sola volta in qualsiasi replica DNS. Esso può comparire in una qualsiasi delle sezioni di risposta, di autorità o delle informazioni aggiuntive, secondo necessità. Tuttavia non dovrebbe essere ripetuto nella stessa sezione, o in qualsiasi altra, salvo dove 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 sia l'ultimo record della replica. Dove i duplicati sono richiesti in questo modo, il TTL trasmesso in ciascun caso deve essere lo stesso.