Per què un registre SRV només ajuda un client que el consulta

Afegir un registre SRV a la vostra zona no ensenya cap client VPN a buscar-lo. El client ha de conèixer l’etiqueta, decidir enviar la consulta i actuar segons el que torni, i el DNS no pot proporcionar les dues primeres coses. Per tant, la majoria de plans SRV fallits són problemes de client disfressats de DNS. Llegiu primer el comportament de descoberta del client i després publiqueu només l’etiqueta que realment consulta.

Un registre que ningú no consulta no pot ajudar ningú

L’SRV publica la ubicació d’un servei; no l’anuncia. Res no empeny un registre cap a un client, i cap resolutor no ofereix un nom que mai no s’ha demanat. La consulta comença quan l’aplicació decideix fer-la, així que l’etiqueta ha de venir de la documentació del producte o de l’observació del programari a la xarxa. On el client no té cap pas de descoberta, un registre canvia la zona i res més.

Per això un producte en una xarxa pot començar a funcionar mentre un altre no es veu afectat pel mateix canvi. La variable és el programari, i el servidor DNS fa exactament el que se li ha dit. Torneu a llegir la zona després de l’edició, perquè una etiqueta mal escrita s’amaga fàcilment entre registres que semblen tots iguals.

Llegiu els camps abans d’escriure’ls

Un registre porta quatre valors, i cadascun respon una pregunta diferent: la prioritat ordena els objectius que el client pot provar, el pes reparteix la càrrega entre objectius de la mateixa prioritat, el port anomena el port de transport i l’objectiu anomena l’amfitrió. L’especificació també permet que un objectiu de . signifiqui que el servei no està disponible deliberadament, cosa que és una resposta útil i no una de trencada.

Cap d’aquests camps no porta credencials, una política de certificats ni una versió de l’aplicació, i un client que ignora el pes igualment es connecta, només que sense l’equilibri previst. L’objectiu necessita registres d’adreça propis, i ha de ser un nom canònic i no un àlies. Publicar un registre que apunta a un amfitrió sense cap receptor produeix un error de connexió que es llegeix com una fallada de DNS, que és el tipus d’engany més car. Publiqueu tota la cadena o res d’ella.

Trobeu l’etiqueta que el client envia realment

Establiu l’etiqueta a partir d’evidències i no d’una suposició sobre el nom del producte. O bé la documentació indica el nom del servei, o bé una captura mostra la consulta que surt del client quan arrenca. Les dues vies acaben al mateix lloc: un nom i un tipus exactes per provar contra el resolutor.

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

Compareu la resposta amb el registre que heu publicat, caràcter a caràcter, perquè els guions baixos i el punt final formen part del nom. Una resposta buida a una consulta que realment s’ha enviat apunta a la zona, mentre que l’absència total de consulta apunta al client, i aquestes troballes us envien a equips diferents. Una resposta real s’assembla a la línia de sota, on la prioritat 20 perd contra qualsevol registre de prioritat més baixa i el client marca el port 8443 a l’objectiu indicat.

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

L’objectiu també ha d’existir

Un objectiu que es resol no és el mateix que un servei que respon. Comproveu els registres d’adreça de l’objectiu i després comproveu que alguna cosa escolta al port i protocol publicats. Un registre TCP que apunta a un receptor només UDP és una dissonància que cap edició de la zona no repara. Mantingueu el TTL curt mentre l’objectiu sigui inestable, i allargueu-lo quan el nom deixi de moure’s.

Els clients que sí que implementen la descoberta varien en quant del registre respecten. Alguns utilitzen només la prioritat, alguns tracten el pes com a consell i uns quants ignoren el port i assumeixen un valor per defecte. Aquestes diferències han de figurar a les vostres notes al costat de l’etiqueta, perquè expliquen un comportament que d’altra manera sembla una fallada del resolutor.

La descoberta no és autenticació

Una resposta SRV diu on connectar-se, i no diu res sobre en qui confiar un cop hi arribeu. Deixeu la validació del certificat i les comprovacions d’identitat del servidor del client exactament com eren, perquè un registre que algú altre pot falsificar no hauria de convertir-se en una decisió de confiança. Les respostes DNS es poden emmagatzemar i editar per qui controla la zona, cosa que les converteix en un mal lloc per codificar polítiques.

Per a un client sense suport de descoberta, distribuïu el perfil o l’URL de passarel·la que sí que accepta, i anoteu quin producte fa servir quin mètode. Aquesta nota evita que el següent administrador afegeixi un registre i esperi que funcioni a tot arreu. L’especificació SRV descriu la selecció entre objectius, i llegir-la com un mecanisme d’autorització és com un registre útil es converteix en una suposició de seguretat. Publiqueu amb intenció, nomeu l’etiqueta a la documentació i tracteu el client com el component que decideix si tot això té cap importància.