1. Introduction (Introduzione)

Nella RFC 1034 [RFC1034], le sezioni 4.3.2 e 4.3.3 descrivono la sintesi di risposte da record di risorse (Resource Records, RRs) speciali chiamati wildcard. La definizione nella RFC 1034 è incompleta e si è dimostrata confusa. Questo documento descrive la sintesi dei wildcard aggiungendo alla discussione e apportando modifiche limitate. Tali modifiche sono state apportate per colmare le incongruenze che hanno portato a problemi di interoperabilità. La descrizione non estende l'ambito del servizio previsto dalla definizione originale.

Rimanendo nello spirito e nello stile dei documenti originali, questo documento evita di specificare regole per le implementazioni DNS riguardanti i wildcard. L'intenzione è solo descrivere ciò che è necessario per l'interoperabilità, non limitare le scelte di implementazione. Questo documento considera inoltre la minimizzazione dei possibili problemi di compatibilità con le implementazioni conformi alla definizione della RFC 1034.

Questo documento si concentra sul concetto di wildcard come definito nella RFC 1034. Non viene implicato nulla riguardo ai mezzi alternativi di sintesi di insiemi di record di risorse (Resource Record Sets, RRSets), né vengono discusse alternative.

1.1 Motivation (Motivazione)

Molte implementazioni DNS divergono, in modi diversi, dalla definizione originale dei wildcard. Sebbene sia chiaro che sia necessario chiarire i documenti originali alla luce di ciò, l'impulso per questo documento risiedeva nell'ingegneria delle estensioni di sicurezza DNS (DNS Security Extensions) [RFC4033]. Con una definizione poco chiara dei wildcard, la progettazione della negazione autenticata (authenticated denial) si è rivelata problematica.

Questo documento limita intenzionalmente le modifiche a ciò che, in base all'esperienza di implementazione, è ritenuto necessario e aderisce il più possibile ai documenti originali. Per enfatizzare che questo documento intende chiarire e adattare i wildcard, anziché ridefinirli, le sezioni pertinenti della RFC 1034 vengono ripetute alla lettera, in modo che il testo nuovo e quello vecchio possano essere confrontati.

1.2 The Original Definition (La definizione originale)

La definizione del concetto di wildcard è composta dalla documentazione dell'algoritmo con cui un server dei nomi prepara una risposta (nella sezione 4.3.2 della RFC 1034) e dal modo in cui un record di risorse (set) viene identificato come fonte di dati sintetici (sezione 4.3.3).

Di seguito viene citato il termine "wildcard" dalla sezione 4.3.3 della RFC 1034.

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.

Questo testo segue immediatamente l'algoritmo che usa per la prima volta il termine wildcard. In questa definizione, wildcard si riferisce al record di risorse. In altri usi, wildcard è stato applicato ai nomi di dominio ed è stato usato anche per descrivere la pratica operativa, dipendente dai wildcard, di generare risposte. Ciò mostra che per discutere i wildcard è necessario definire termini chiari e non ambigui.

La sezione 4.3.2 della RFC 1034 è intitolata "Algorithm" (Algoritmo) e la parte 'c' del passo 3 menziona l'uso dei wildcard nella preparazione di una risposta. Si noti che la parola "wildcard" non compare nell'algoritmo; l'algoritmo fa riferimento all'etichetta "*". La sezione 3 di questo documento scompone in dettaglio le parti dell'algoritmo relative ai wildcard. Di seguito è riportato l'inizio pertinente dell'algoritmo tratto da "Algorithm".

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

L'ambito di questo documento è la definizione di wildcard della RFC 1034, nonché l'impatto degli aggiornamenti di tali documenti, come ad esempio DNS Security (DNSSEC). Questo documento non prende in considerazione alternative alla sintesi delle risposte. (Si noti che qui non vengono elencati riferimenti. Non si conoscono al momento documenti che descrivano alternative, sebbene vi siano stati accenni nelle mailing list.)

1.3 Roadmap to This Document (Roadmap di questo documento)

Questo documento compie questi tre compiti:

Definisce nuovi termini
Apporta modifiche minori per evitare concetti contrastanti
Descrive le azioni di determinati record di risorse come wildcard

1.3.1 New Terms (Nuovi termini)

Per agevolare la discussione su quali record di risorse siano wildcard, questo documento definisce due termini: "asterisk label" (etichetta asterisco) e "wildcard domain name" (nome di dominio wildcard). Questi termini sono definiti nella sezione 2.1.1.

Per aiutare a chiarire il ruolo dei wildcard nell'algoritmo del server dei nomi della sezione 4.3.2 della RFC 1034, questo documento definisce "source of synthesis" (fonte di sintesi) e "closest encloser" (racchiudente più prossimo). Questi termini sono definiti nella sezione 3.3.1.

1.3.2 Changed Text (Testo modificato)

Sostituendo il testo della sezione 4.3.3 della RFC 1034 con il testo della sezione 2.1 di questo documento, la definizione di ciò che sono i "wildcard" è stata modificata. Il testo sostitutivo definisce "wildcard domain name" (nome di dominio wildcard) e "asterisk label" (etichetta asterisco) come termini. Ciò non intende modificarne il significato, ma esprimerlo in modo più chiaro.

Il motivo di questa modifica è che nella RFC 1034 il termine wildcard è definito in due modi. Nella sezione 4.3.3, "wildcard" viene usato per denominare i record di risorse. Nell'algoritmo della sezione 4.3.2, i "wildcard" sono nomi di dominio ed etichette, non record di risorse. Poiché in quest'ultimo caso non è chiaro se il termine "wildcard" sia un uso o due usi (uno per l'etichetta, uno per il nome), sono stati introdotti nuovi termini.

Una parte dell'algoritmo del passo 3 della sezione 4.3.2 della RFC 1034 è stata modificata e viene fornita nella sezione 3.3.3 di questo documento. Ciò si basa sul consentire la sintesi di alcuni tipi e sul vietare che alcuni tipi siano fonti di sintesi, come SIG (il vecchio nome di RRSIG).

1.3.3 Considerations with Special Types (Considerazioni sui tipi speciali)

La sezione 4 esamina vari tipi di record di risorse e spiega come dovrebbero e non dovrebbero essere trattati.

La RFC 1034 afferma che CNAME è un tipo che non può coesistere con altri dati. Tuttavia, poiché il testo "wildcard" è stato revisionato, è necessario discutere il divieto di sintesi quando un CNAME RRSet è presente nella fonte di sintesi.

L'interazione di altri tipi di record di risorse con i wildcard viene discussa in base al loro stato: standard, sperimentale, obsoleto e ritirato.

1.4 Standards Terminology (Terminologia degli standard)

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 nella RFC 2119 [RFC2119].

Poiché queste parole chiave vengono utilizzate solo nella discussione del protocollo, l'unica sezione pertinente è la sezione 4, e la sezione 4 fa riferimento alla sezione 3. Il resto di questo documento ha solo scopo esplicativo e di chiarimento dei concetti.

La RFC 1034 usa il termine "authoritative" (autorevole) per descrivere un server dei nomi che possiede "the complete information for a zone" (le informazioni complete per una zona). Per evitare confusione, questo documento usa i termini "authoritative name server" (server dei nomi autorevole) e "zone" (zona) per descrivere la stessa relazione della RFC 1034, ovvero che un server dei nomi è autorevole per il contenuto di una particolare zona. Questa distinzione viene fatta perché un server dei nomi è in genere autorevole per più zone, ma non per l'intero albero DNS.