3. Overview (Panoramica)
3. Overview (Panoramica)
Un client DNS Push Notification si iscrive alle Push Notifications per un particolare RRset connettendosi al server Push Notification appropriato per quell'RRset e inviando messaggi DSO che indicano gli RRset di interesse. Quando il client perde interesse a ricevere ulteriori aggiornamenti di questi record, annulla l'iscrizione.
Il server DNS Push Notification per una zona DNS è qualsiasi server in grado di generare le corrette notifiche di modifica per un nome. Può essere un name server primario, secondario o stealth [RFC8499].
Il record SRV "_dns-push-tls._tcp.<zone>" per una zona PUÒ fare riferimento allo stesso host di destinazione e porta del record SRV "_dns-update-tls._tcp.<zone>" di quella zona. Quando lo stesso host di destinazione e porta viene offerto sia per DNS Updates che per DNS Push Notifications, un client PUÒ utilizzare una singola sessione DSO verso quel server sia per DNS Updates che per sottoscrizioni DNS Push Notification. DNS Updates e DNS Push Notifications possono essere gestiti su porte diverse sullo stesso host di destinazione, nel qual caso non sono considerati lo "stesso server" ai fini di questa specifica, e le comunicazioni con queste due porte sono gestite indipendentemente. Il supporto di DNS Updates e DNS Push Notifications sullo stesso server è OPZIONALE. Un server DNS Push Notification non è tenuto a supportare DNS Update.
Query DNS standard POSSONO essere inviate su una sessione DNS Push Notification (cioè DSO). Per qualsiasi zona per la quale il server è autoritativo, DEVE rispondere in modo autoritativo alle query per nomi che rientrano in quella zona (ad esempio, il record SRV "_dns-push-tls._tcp.<zone>") sia per query DNS normali che per sottoscrizioni DNS Push Notification. Per nomi per i quali il server agisce come resolver ricorsivo (ad esempio, quando il server è il resolver ricorsivo locale), per qualsiasi query per la quale supporta sottoscrizioni DNS Push Notification, DEVE anche supportare query standard.
Le DNS Push Notifications impongono meno carico al server rispondente rispetto a quanto farebbe un polling rapido, ma le Push Notifications hanno comunque un costo. Pertanto, i client DNS Push Notification NON DEVONO creare in modo sconsiderato un numero eccessivo di sottoscrizioni Push Notification. In particolare:
(a) Una sottoscrizione dovrebbe essere attiva solo quando esiste una ragione valida per aver bisogno di dati in tempo reale (ad esempio, un display su schermo sta attualmente mostrando i risultati all'utente), e la sottoscrizione DOVREBBE essere annullata non appena la necessità di tali dati termina (ad esempio, quando l'utente chiude quel display). Nel caso di un dispositivo come uno smartphone che, dopo un certo periodo di inattività, va in sospensione o altrimenti oscura il suo schermo, dovrebbe annullare le sue sottoscrizioni quando oscura lo schermo (poiché l'utente non può comunque vedere alcuna modifica sul display) e ripristinare le sue sottoscrizioni quando si risveglia dalla sospensione del display.
(b) Un client DNS Push Notification NON DOVREBBE mantenere di routine una sottoscrizione DNS Push Notification attiva 24 ore al giorno, 7 giorni alla settimana, solo per mantenere un elenco in memoria aggiornato in modo che se l'utente sceglie di richiamare un display su schermo di tali dati, possa essere visualizzato molto velocemente. Le DNS Push Notifications sono progettate per essere abbastanza veloci da non richiedere di precaricare un elenco "caldo" in memoria nel caso in cui potrebbe essere necessario in seguito.
In generale, come descritto nella specifica DNS Stateful Operations [RFC8490], un client non deve mantenere una sessione DSO verso un server aperta indefinitamente se non ha sottoscrizioni (o altre operazioni) attive su quella sessione. Un client dovrebbe iniziare a chiudere una sessione DSO immediatamente dopo che diventa inattiva, e quindi, se necessario in futuro, aprire una nuova sessione quando richiesto. In alternativa, un client può speculativamente mantenere una sessione DSO inattiva aperta per un certo tempo, soggetto al vincolo che non deve mantenere aperta una sessione che è rimasta inattiva per più del timeout di inattività della sessione (15 secondi per impostazione predefinita) [RFC8490].
Si noti che una sessione DSO che ha una sottoscrizione DNS Push Notification attiva non è considerata inattiva, anche se non c'è traffico in corso per un periodo di tempo prolungato. In questo caso, il timeout di inattività DSO non si applica, perché la sessione non è inattiva, ma l'intervallo di keepalive si applica ancora, per garantire la generazione di messaggi sufficienti per mantenere lo stato nei middlebox (come gateway NAT o firewall) e per consentire al client e al server di verificare periodicamente di avere ancora connettività l'uno con l'altro. Questo è descritto nella sezione 6.2 della specifica DSO [RFC8490].