Perché un record SRV aiuta solo un client che lo interroga

Aggiungere un record SRV alla vostra zona non insegna a nessun client VPN a cercarlo. Il client deve conoscere l’etichetta, decidere di inviare la query e agire in base a ciò che torna, e il DNS non può fornire le prime due cose. Per questo la maggior parte dei piani SRV falliti sono problemi di client mascherati da DNS. Leggete prima il comportamento di scoperta del client, poi pubblicate solo l’etichetta che interroga davvero.

Un record che nessuno interroga non può aiutare nessuno

SRV pubblica la posizione di un servizio; non lo annuncia. Niente spinge un record verso un client, e nessun resolver offre un nome che non è mai stato chiesto. La ricerca inizia quando l’applicazione decide di farla, quindi l’etichetta deve venire dalla documentazione del prodotto o dall’osservazione del software sulla rete. Dove il client non ha alcun passo di scoperta, un record cambia la zona e nient’altro.

Ecco perché un prodotto su una rete può iniziare a funzionare mentre un altro non è toccato dallo stesso cambiamento. La variabile è il software, e il server DNS fa esattamente ciò che gli è stato detto. Rileggete la zona anche dopo la modifica, perché un’etichetta digitata male si nasconde facilmente tra record che sembrano tutti uguali.

Leggete i campi prima di scriverli

Un record porta quattro valori, e ciascuno risponde a una domanda diversa: la priorità ordina le destinazioni che un client può provare, il peso ripartisce il carico tra destinazioni di pari priorità, la porta nomina la porta di trasporto e la destinazione nomina l’host. La specifica consente anche una destinazione di . per indicare che il servizio è deliberatamente non disponibile, che è una risposta utile e non una rotta.

Nessuno di questi campi porta credenziali, una politica di certificati o una versione dell’applicazione, e un client che ignora il peso si connette comunque, solo senza l’equilibrio previsto. La destinazione ha bisogno di propri record di indirizzo, e dovrebbe essere un nome canonico anziché un alias. Pubblicare un record che punta a un host senza alcun ricevitore produce un errore di connessione che si legge come un guasto DNS, ed è il tipo di inganno più costoso. Pubblicate l’intera catena o niente di essa.

Trovate l’etichetta che il client invia davvero

Stabilite l’etichetta dalle prove e non da una supposizione sul nome del prodotto. O la documentazione indica il nome del servizio, o una cattura mostra la query che esce dal client all’avvio. Entrambe le strade finiscono nello stesso punto: un nome e un tipo esatti da provare contro il resolver.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Confrontate la risposta con il record che avete pubblicato, carattere per carattere, perché i trattini bassi e il punto finale fanno parte del nome. Una risposta vuota a una query realmente inviata punta alla zona, mentre l’assenza totale di query punta al client, e questi risultati vi mandano da team diversi. Una risposta reale somiglia alla riga qui sotto, dove la priorità 20 perde contro qualunque record di priorità inferiore e il client compone la porta 8443 sulla destinazione indicata.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Anche la destinazione deve esistere

Una destinazione che si risolve non è la stessa cosa di un servizio che risponde. Controllate i record di indirizzo della destinazione, poi controllate che qualcosa sia in ascolto sulla porta e sul protocollo pubblicati. Un record TCP che punta a un ricevitore solo UDP è un’incoerenza che nessuna modifica della zona ripara. Tenete il TTL breve finché la destinazione è in movimento, e allungatelo quando il nome smette di muoversi.

I client che implementano davvero la scoperta variano in quanto del record rispettano. Alcuni usano solo la priorità, altri trattano il peso come un consiglio e pochi ignorano la porta e assumono un valore predefinito. Queste differenze vanno nelle vostre note accanto all’etichetta, perché spiegano un comportamento che altrimenti sembra un guasto del resolver.

La scoperta non è autenticazione

Una risposta SRV dice dove connettersi, e non dice nulla su di chi fidarsi una volta arrivati. Lasciate la validazione del certificato e i controlli di identità del server del client esattamente com’erano, perché un record che altri possono falsificare non dovrebbe diventare una decisione di fiducia. Le risposte DNS sono memorizzabili e modificabili da chi controlla la zona, il che le rende un cattivo posto per codificare una politica.

Per un client senza supporto di scoperta, distribuite il profilo o l’URL del gateway che accetta, e annotate quale prodotto usa quale metodo. Quella nota impedisce all’amministratore successivo di aggiungere un record e aspettarsi che funzioni ovunque. La specifica SRV descrive la selezione tra destinazioni, e leggerla come meccanismo di autorizzazione è il modo in cui un record utile diventa un’ipotesi di sicurezza. Pubblicate con intenzione, nominate l’etichetta nella documentazione e trattate il client come il componente che decide se tutto questo ha importanza.