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.

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 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].

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).

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.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].