6.1. Discovery (Scoperta)

6.1. Discovery (Scoperta)

Il primo passo per stabilire una sottoscrizione DNS Push Notification consiste nel scoprire un server DNS appropriato che supporti le DNS Push Notifications per la zona desiderata.

Il client inizia aprendo una sessione DSO verso il suo resolver ricorsivo DNS normalmente configurato e richiedendo una sottoscrizione Push Notification. Questa connessione viene effettuata sulla porta TCP 853, la porta predefinita per DNS over TLS [RFC7858]. Se la richiesta di sottoscrizione Push Notification ha successo e il resolver ricorsivo non ha già una sottoscrizione attiva per quel nome, tipo e classe, allora il resolver ricorsivo creerà una sottoscrizione Push Notification corrispondente per conto del client. I risultati ricevuti vengono inoltrati al client. Questo è strettamente analogo a come un client invia una normale query DNS al suo resolver ricorsivo DNS configurato, che, se non ha già risposte appropriate nella sua cache, emette una query upstream per soddisfare la richiesta.

In molti contesti, il resolver ricorsivo sarà in grado di gestire Push Notifications per tutti i nomi che il client potrebbe aver bisogno di seguire. L'uso di tunnel VPN e DNS privato [RFC8499] può creare una certa complessità aggiuntiva nel software client qui; le tecniche per gestire i tunnel VPN e il DNS privato per le DNS Push Notifications sono le stesse di quelle già utilizzate per gestire questo per le query DNS normali.

Se il resolver ricorsivo non supporta DNS over TLS, o supporta DNS over TLS ma non è in ascolto sulla porta TCP 853, o supporta DNS over TLS sulla porta TCP 853 ma non supporta DSO su quella porta, allora l'instaurazione della sessione DSO fallirà [RFC8490].

Se il resolver ricorsivo supporta DSO sulla porta TCP 853 ma non supporta le sottoscrizioni Push Notification, allora quando il client tenta di creare una sottoscrizione, il server restituirà il codice di errore DSO DSOTYPENI (11).

In alcuni casi, il resolver ricorsivo può supportare DSO e sottoscrizioni Push Notification ma potrebbe non essere in grado di sottoscrivere Push Notifications per un nome particolare. In questo caso, il resolver ricorsivo dovrebbe restituire SERVFAIL al client. Questo include l'impossibilità di stabilire una connessione al server DNS Push Notification della zona o stabilire una connessione ma ricevere un codice di risposta non riuscito. In alcuni casi, dove il client ha una relazione di fiducia prestabilita con il proprietario della zona (che non è gestita tramite i meccanismi usuali per il software VPN), il client può gestire questi fallimenti contattando direttamente il server DNS Push Notification della zona.

In uno qualsiasi dei casi descritti sopra in cui il client non riesce a stabilire una sottoscrizione DNS Push Notification tramite il suo resolver ricorsivo configurato, il client dovrebbe procedere a scoprire il server appropriato per la comunicazione diretta. Il client DEVE anche determinare su quale porta TCP il server è in ascolto per le connessioni, che non deve necessariamente essere, e spesso non è, la porta TCP 53 (tradizionalmente utilizzata per il DNS convenzionale) o la porta TCP 853 (tradizionalmente utilizzata per DNS over TLS).

L'algoritmo di scoperta descritto qui è un algoritmo iterativo, che inizia con il nome completo del record a cui il client desidera sottoscrivere. Vengono quindi emesse query SOA successive, rimuovendo un'etichetta ogni volta, fino a quando non viene scoperto il server autoritativo più vicino che lo racchiude. C'è anche un'ottimizzazione per consentire al client di prendere una "scorciatoia" direttamente al record SOA del server autoritativo più vicino che lo racchiude in molti casi.

1. Il client inizia la scoperta inviando una query DNS al suo resolver locale, con tipo di record SOA [RFC1035] per il nome del record a cui desidera sottoscrivere. Come esempio, supponiamo che il client desideri sottoscrivere i record PTR con il nome "_ipp._tcp.headoffice.example.com" (per scoprire le stampanti Internet Printing Protocol (IPP) [RFC8010] [RFC8011] pubblicizzate nella sede centrale di Example Company). Il client inizia inviando una query SOA per "_ipp._tcp.headoffice.example.com" al resolver ricorsivo locale. L'obiettivo è determinare il server che è autoritativo per il nome "_ipp._tcp.headoffice.example.com". La zona DNS più vicina che racchiude il nome "_ipp._tcp.headoffice.example.com" potrebbe essere "example.com", o "headoffice.example.com", o "_tcp.headoffice.example.com", o persino "_ipp._tcp.headoffice.example.com". Il client non sa in anticipo dove si verifica il taglio della zona più vicina che la racchiude, motivo per cui utilizza la procedura iterativa descritta qui per scoprire queste informazioni.

2. Se il record SOA richiesto esiste, verrà restituito nella sezione Answer con un codice di risposta NOERROR, e il client è riuscito a scoprire le informazioni di cui ha bisogno. (Questo linguaggio non pone nuovi requisiti sui resolver ricorsivi DNS. Questo testo descrive semplicemente il funzionamento esistente del protocollo DNS [RFC1034] [RFC1035].)

3. Se il record SOA richiesto non esiste, il client riceverà una risposta NOERROR/NODATA o una risposta NXDOMAIN/Name Error. In entrambi i casi, il resolver locale includerebbe normalmente il record SOA per la zona più vicina che racchiude il nome richiesto nella sezione Authority. Se il record SOA viene ricevuto nella sezione Authority, allora il client è riuscito a scoprire le informazioni di cui ha bisogno. (Questo linguaggio non pone nuovi requisiti sui resolver ricorsivi DNS. Questo testo descrive semplicemente il funzionamento esistente del protocollo DNS riguardo alle risposte negative [RFC2308].)

4. Se il client riceve una risposta che non contiene alcun record SOA, allora procede con l'approccio iterativo. Il client rimuove l'etichetta principale dal nome di query corrente, e se il nome risultante ha almeno due etichette, allora il client invia una query SOA per quel nuovo nome e l'elaborazione continua al passo 2 sopra, ripetendo la ricerca iterativa fino a quando non viene ricevuto un SOA o il nome di query consiste in una singola etichetta, cioè un dominio di primo livello (TLD). Nel caso di un nome a etichetta singola (TLD), questo è un errore di configurazione di rete, che non dovrebbe accadere, e il client rinuncia. Il client può riprovare l'operazione in un momento successivo scelto dal client, come dopo un cambio di connessione di rete.

5. Una volta che il SOA è noto (in virtù di essere visto nella sezione Answer o nella sezione Authority), il client invia una query DNS con tipo SRV [RFC2782] per il nome di record "_dns-push-tls._tcp.<zone>", dove <zone> è il nome del proprietario del record SOA scoperto.

6. Se la zona in questione è configurata per offrire DNS Push Notifications, allora questo record SRV DEVE esistere. (Se questo record SRV non esiste, allora la zona non è configurata correttamente per le DNS Push Notifications come specificato in questo documento.) Il "target" SRV contiene il nome del server che fornisce DNS Push Notifications per la zona. Il numero di porta su cui contattare il server è nel campo "port" del record SRV. Gli indirizzi dell'host di destinazione POSSONO essere inclusi nella sezione Additional, tuttavia, i record di indirizzo DOVREBBERO essere autenticati prima dell'uso come descritto nella sezione 7.2 e nella specifica per l'utilizzo di DNS-Based Authentication of Named Entities (DANE) TLSA Records con SRV Records [RFC7673], se applicabile.

7. Può essere restituito più di un record SRV. In questo caso, i valori "priority" e "weight" nei record SRV restituiti vengono utilizzati per determinare l'ordine in cui contattare i server per le richieste di sottoscrizione. Come descritto nella specifica SRV [RFC2782], il server con la "priority" più bassa viene contattato per primo. Se più di un server ha la stessa "priority", il "weight" indica la probabilità ponderata che il client dovrebbe contattare quel server. Pesi più alti hanno probabilità di selezione più elevate. Se un server non è disposto ad accettare una richiesta di sottoscrizione, o non è raggiungibile entro un tempo ragionevole, come determinato dal client, allora deve essere contattato un server successivo.

Ogni volta che un client crea una nuova sottoscrizione DNS Push Notification, DOVREBBE ripetere il processo di scoperta al fine di determinare il server DNS preferito per quella sottoscrizione in quel momento. Se un client ha già una sessione DSO con quel server DNS, il client DOVREBBE riutilizzare quella sessione DSO esistente per la nuova sottoscrizione; altrimenti, viene stabilita una nuova sessione DSO. Il client DEVE rispettare i valori TTL DNS sui record che riceve durante l'esecuzione del processo di scoperta e memorizzarli nella sua cache locale con questa durata (come farà generalmente comunque per tutte le query DNS che esegue). Ciò significa che, finché i valori TTL DNS sui record autoritativi sono impostati su valori ragionevoli, l'applicazione ripetuta del processo di scoperta può essere completata praticamente istantaneamente dal client, utilizzando solo dati memorizzati nella cache localmente.