Por que un rexistro SRV só axuda a un cliente que o consulta

Engadir un rexistro SRV á súa zona non lle ensina a ningún cliente VPN a buscalo. O cliente ten que coñecer a etiqueta, decidir enviar a consulta e actuar segundo o que volva, e o DNS non pode fornecer as dúas primeiras cousas. Por iso a maioría dos plans SRV fallidos son problemas de cliente disfrazados de DNS. Lea primeiro o comportamento de descubrimento do cliente e logo publique só a etiqueta que realmente consulta.

Un rexistro que ninguén consulta non pode axudar a ninguén

O SRV publica a localización dun servizo; non o anuncia. Nada empurra un rexistro cara a un cliente, e ningún resolvedor ofrece un nome que nunca se pediu. A busca comeza cando a aplicación decide facela, así que a etiqueta ten que vir da documentación do produto ou de observar o software na rede. Onde o cliente non ten ningún paso de descubrimento, un rexistro cambia a zona e nada máis.

Por iso un produto nunha rede pode comezar a funcionar mentres outro non se ve afectado polo mesmo cambio. A variable é o software, e o servidor DNS fai exactamente o que se lle dixo. Volva ler a zona despois da edición, porque unha etiqueta mal escrita escóndese con facilidade entre rexistros que parecen todos iguais.

Lea os campos antes de escribilos

Un rexistro leva catro valores, e cada un responde a unha pregunta distinta: a prioridade ordena os destinos que un cliente pode probar, o peso reparte a carga entre destinos de igual prioridade, o porto nomea o porto de transporte e o destino nomea o host. A especificación tamén permite que un destino de . signifique que o servizo non está dispoñible a propósito, o cal é unha resposta útil e non unha rota.

Ningún deses campos leva credenciais, unha política de certificados nin unha versión da aplicación, e un cliente que ignora o peso conéctase igual, só que sen o equilibrio previsto. O destino necesita rexistros de enderezo propios, e debería ser un nome canónico en lugar dun alias. Publicar un rexistro que apunta a un host sen ningún receptor produce un erro de conexión que se le como un fallo de DNS, e ese é o tipo de engano máis caro. Publique toda a cadea ou nada dela.

Achegue a etiqueta que o cliente envía de verdade

Estableza a etiqueta a partir de probas e non dunha suposición sobre o nome do produto. Ou ben a documentación indica o nome do servizo, ou ben unha captura mostra a consulta que sae do cliente ao arrincar. Ámbalas rutas rematan no mesmo punto: un nome e un tipo exactos para probar contra o resolvedor.

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

Compare a resposta co rexistro que publicou, carácter a carácter, porque os guións baixos e o punto final forman parte do nome. Unha resposta baleira a unha consulta que si se enviou apunta á zona, mentres que a ausencia total de consulta apunta ao cliente, e esas achádegas lévano a equipos distintos. Unha resposta real parécese á liña de abaixo, onde a prioridade 20 perde fronte a calquera rexistro de prioridade máis baixa e o cliente marca o porto 8443 no destino indicado.

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

O destino tamén ten que existir

Un destino que resolve non é o mesmo que un servizo que responde. Comprobe os rexistros de enderezo do destino e logo comprobe que algo escoita no porto e o protocolo publicados. Un rexistro TCP que apunta a un receptor só UDP é unha discrepancia que ningunha edición da zona repara. Manteña o TTL curto mentres o destino sexa inestable, e alárgueo cando o nome deixe de moverse.

Os clientes que si implementan o descubrimento varían en canto do rexistro respectan. Algúns usan só a prioridade, outros tratan o peso como consello e uns poucos ignoran o porto e supoñen un valor por defecto. Esas diferenzas pertencen ás súas notas xunto á etiqueta, porque explican un comportamento que doutro xeito parece un fallo do resolvedor.

O descubrimento non é autenticación

Unha resposta SRV di a onde conectarse, e non di nada sobre en quen confiar unha vez que chega. Deixe a validación do certificado e as comprobacións de identidade do servidor do cliente exactamente como estaban, porque un rexistro que outro pode falsificar non debería converterse nunha decisión de confianza. As respostas DNS pódense almacenar e editar por quen controla a zona, o que as converte nun mal lugar para codificar políticas.

Para un cliente sen soporte de descubrimento, distribúa o perfil ou a URL de pasarela que si acepta, e anote que produto usa que método. Esa nota impide que o seguinte administrador engada un rexistro e espere que funcione en todas partes. A especificación SRV describe a selección entre destinos, e lela como un mecanismo de autorización é a forma en que un rexistro útil se converte nunha suposición de seguridade. Publique a conciencia, nomee a etiqueta na súa documentación e trate o cliente como o compoñente que decide se algo disto importa.