3. Impact of a Wildcard Domain Name on a Response (Impatto)

3. Impact of a Wildcard Domain Name on a Response (Impatto di un nome di dominio wildcard su una risposta)

L'algoritmo della RFC 1034, sezione 4.3.2, rimane invariato, salvo quanto specificato nella sezione 3.3.3 di questo documento. Il problema risiede nell'interpretazione dell'algoritmo nella sezione 4.3.2, passo 3, parte 'c' della RFC 1034, come indicato nella sezione 4.3.3 della RFC 1034, che definisce i wildcard.

Nelle spiegazioni che seguono, quando si fa riferimento alla RFC 1034, il testo si applica anche qualora vengano applicati eventuali aggiornamenti della RFC 1034 (come [RFC2672], che definisce DNAME).

3.1 Step 2 (Passo 2)

Il passo 2 dell'algoritmo di ricerca consiste nel "trovare la corrispondenza più lunga possibile". È stato sostenuto che un riferimento memorizzato nella cache soddisfa la questione della "corrispondenza più lunga" ed elimina la necessità di proseguire con i passi successivi. Ciò è errato. Il completamento del passo 2 include la determinazione che esista una corrispondenza più lunga disponibile più avanti nella gerarchia DNS.

3.2 Step 3 (Passo 3)

Il passo 3 dell'algoritmo di ricerca nella RFC 1034, sezione 4.3.2, è il luogo in cui i wildcard vengono richiamati, ma solo se un insieme di record di risorse corrispondente al tipo della query non viene trovato al nome di dominio. Questa è la parte 'c' del passo 3. La frase è la seguente:

# c. If at some label, a match is impossible (i.e., the
#    corresponding label does not exist), look to see if [...]
#    the "*" label exists.
#
#    If the "*" label does not exist, check whether the name
#    we are looking for is the original QNAME in the query
#    or a name we have followed due to a CNAME.  If the name
#    is original, set an authoritative name error in the
#    response and exit.  Otherwise just exit.
#
#    If the "*" label does exist, match RRs at that node
#    against QTYPE.  If any match, copy them into the answer
#    section, but set the owner of the RR to be QNAME, and
#    not the node with the "*" label. [...]

3.3 Part 'c' (Parte 'c')

Questa è la discussione sul testo "look to see" citato dalla sezione 4.3.2, passo 3, parte 'c' della RFC 1034.

3.3.1 Closest Encloser and the Source of Synthesis (Racchiudente più prossimo e fonte di sintesi)

Il "closest encloser" (racchiudente più prossimo) è il nodo nell'albero dei nomi di dominio esistenti della zona che ha il maggior numero di etichette che corrispondono a un nome di query (consecutivamente, contando dalla radice verso il basso). Ogni corrispondenza è un "label match" (corrispondenza di etichetta) e il conteggio del numero di etichette corrispondenti è la "closest encloser proof" (prova del racchiudente più prossimo). In un certo senso, il racchiudente più prossimo è il nome di dominio esistente più profondo nella zona che è un antenato del nome di query.

La "source of synthesis" (fonte di sintesi) è il nome di dominio wildcard che discende immediatamente dal racchiudente più prossimo, a condizione che un nome di dominio wildcard appaia in quella posizione nella zona. La fonte di sintesi è determinata anteponendo l'etichetta asterisco ("*") al racchiudente più prossimo.

L'uso della frase "source of synthesis" (fonte di sintesi) per descrivere il nome di dominio wildcard coinvolto nella sintesi dei wildcard fornisce una terminologia utile e non causa problemi nel descrivere l'uso di nomi che non hanno un'etichetta asterisco nella posizione meno significativa, poiché tali nomi non sono nomi di dominio wildcard.

3.3.2 Closest Encloser and Source of Synthesis Examples (Esempi di racchiudente più prossimo e fonte di sintesi)

Questo viene illustrato utilizzando la zona dell'esempio della sezione 2.2.1:

Per il nome di query "host.example.", il racchiudente più prossimo è "example." e la fonte di sintesi è "*.example.".

Per il nome di query "a.host.example.", il racchiudente più prossimo è "host.example." e la fonte di sintesi è "*.host.example.", ma questo nome di dominio wildcard non fa parte della zona e non esiste.

Per il nome di query "_telnet._tcp.host.example.", esiste una corrispondenza esatta e non vi è alcuna fonte di sintesi. Ciò è dovuto al fatto che una corrispondenza esatta ha la precedenza sulla corrispondenza wildcard.

Per il nome di query "_dns._udp.host.example.", il racchiudente più prossimo è "host.example." e la fonte di sintesi è "*.host.example.", ma questo nome di dominio wildcard non esiste nella zona e non vi è alcuna fonte di sintesi.

Per il nome di query "*.example.", esiste una corrispondenza esatta e non vi è alcuna fonte di sintesi.

Per il nome di query "a..example.", il racchiudente più prossimo è ".example." e la fonte di sintesi è "..example.", ma questa non esiste nella zona e non vi è alcuna fonte di sintesi.

Per il nome di query "_telnet._tcp..example.", il racchiudente più prossimo è ".example." e la fonte di sintesi è "..example.", ma questa non esiste nella zona e non vi è alcuna fonte di sintesi.

Per il nome di query "host3..example.", il racchiudente più prossimo è ".example." e la fonte di sintesi è "..example.", ma questa non esiste nella zona. Non vi è alcuna fonte di sintesi. Ciò che è istruttivo in questo caso è che "host3.*.example." esiste, ma non è la fonte di sintesi né di se stesso né di un altro nome.

Il punto essenziale di questi esempi è l'identificazione del racchiudente più prossimo e della fonte di sintesi, e non ciò che il server dei nomi risponde in qualità di autorità (risposta, delega, NXDOMAIN o NOERROR/NODATA).

3.3.3 Type Matching (Corrispondenza di tipo)

La sezione 4.3.3 della RFC 1034 afferma:

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

e

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.

Il primo brano citato descrive la sintesi di record da un wildcard RRSet modificando il nome del proprietario del RR. Il secondo brano citato afferma "match RRs ... against QTYPE" (fai corrispondere i RR ... con QTYPE) e copia solo in caso di corrispondenza. È evidente che, come per tutte le corrispondenze di nome, possono essere copiati solo i RR di tipo QTYPE. Se QTYPE non è CNAME (o QTYPE è ANY), non vi è alcuna corrispondenza CNAME. La presenza di CNAME esclude la presenza di altri tipi.

Nel caso di un wildcard CNAME, il CNAME RRSet non corrisponde a una query non CNAME e non viene utilizzato per la sintesi. Ciò è simile al caso in cui un CNAME RRSet presente in un nodo terminale viene ignorato quando il tipo richiesto non è CNAME.

Nel caso di un wildcard CNAME RRSet, la frase che descrive la sintesi è stata modificata. Dalla RFC 1034:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.  Go
# to step 6.

è stata modificata come segue:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.
# If QTYPE is CNAME, continue with step 3.d.
# If QTYPE is not CNAME and a CNAME RRSet exists at the node,
# copy the CNAME RRSet into the answer section,
# but set the owner of the RRSet to be QNAME,
# and not the node with the "*" label.
# Go to step 6.

La confusione è stata causata da questo paragrafo nella RFC 1034:

# To illustrate the use of wildcard RRs, suppose a large company with
# a large IT staff wanted to provide a TELNET gateway

La confusione è nata dall'esempio che suggeriva che un CNAME RR sintetizzato da un wildcard venisse poi utilizzato per ottenere un indirizzo per una query A. Un'interpretazione è che il wildcard sia una sorta di "macro-expansion" (espansione di macro) e che questo esempio mostri come rispondere a una query A quando è presente un wildcard CNAME. Un'altra interpretazione è che si tratti di un caso speciale. Una terza interpretazione è che il wildcard debba essere espanso quando i dati di zona vengono caricati nel server e poi applicato senza regole di espansione speciali.

La posizione adottata dal gruppo di lavoro è che questo esempio è anomalo e crea più confusione che insegnamenti. Modificando il testo dell'algoritmo, si chiarisce che questo esempio è un uso errato dei wildcard.

3.4 Authoritative Name Error (Errore di nome autorevole)

Con la definizione sopra di una voce di zona che si trova sotto la cima della zona, nonché del racchiudente più prossimo e della fonte di sintesi, il passo 3.c dell'algoritmo della RFC 1034 (come corretto sopra) produce una risposta di errore di nome autorevole (NXDOMAIN) quando non può essere trovata alcuna fonte di sintesi. Non viene restituita alcuna risposta di errore di nome autorevole se viene trovata una fonte di sintesi, indipendentemente dal fatto che vi sia o meno una corrispondenza di tipo.

3.5 Empty Non-terminals (Non terminali vuoti)

Si noti che se esiste un nome di dominio wildcard "*.example.", allora "example." (il racchiudente più prossimo) è un non terminale vuoto. Lo stesso vale per tutti gli antenati di un nome di dominio wildcard delegato o che possiede record diversi dai record di zona; tali antenati sono non terminali vuoti. Un non terminale vuoto non è una risposta di errore di nome autorevole, poiché il racchiudente più prossimo esiste.