Bakit ang SRV record ay tumutulong lamang sa client na mismo ang nagtatanong nito

Ang pagdaragdag ng SRV record sa iyong zone ay hindi nagtuturo sa alinmang VPN client na hanapin ito. Kailangang malaman ng client ang label, magpasya na ipadala ang query at kumilos ayon sa bumabalik, at hindi maibibigay ng DNS ang unang dalawa. Kaya karamihan ng nabigong plano sa SRV ay mga problema ng client na nakasuot ng DNS. Basahin muna ang pag-uugali ng pagtuklas ng client, pagkatapos ay ilathala lamang ang label na talagang itinatanong nito.

Ang record na walang nagtatanong ay hindi makatutulong sa sinuman

Inilalathala ng SRV ang lokasyon ng isang serbisyo; hindi nito ito inaanunsyo. Walang nagtutulak ng record patungo sa client, at walang resolver ang kusang nag-aalok ng pangalan na hindi kailanman hiniling. Nagsisimula ang paghahanap kapag nagpasya ang aplikasyon na gawin ito, kaya ang label ay dapat magmula sa dokumentasyon ng produkto o sa pagmamasid sa software sa network. Kung saan walang hakbang ng pagtuklas ang client, binabago ng record ang zone at wala nang iba.

Iyon ang dahilan kung bakit ang isang produkto sa isang network ay maaaring magsimulang gumana habang ang isa ay hindi apektado ng parehong pagbabago. Ang variable ay ang software, at ginagawa ng DNS server ang eksaktong sinabi dito. Basahin muli ang zone pagkatapos ng pag-edit, dahil ang maling naipasok na label ay madaling nagtatago sa mga record na magkakamukha.

Basahin ang mga field bago isulat

May dala ang record na apat na halaga, at bawat isa ay sumasagot sa ibang tanong: inaayos ng priority ang mga target na maaaring subukan ng client, hinahati ng weight ang kargada sa mga target na magkapareho ng priority, pinapangalanan ng port ang transport port, at pinapangalanan ng target ang host. Pinapayagan din ng spec ang target na . upang mangahulugan na sadyang hindi available ang serbisyo, na kapaki-pakinabang na sagot at hindi sira.

Wala sa mga field na ito ang may dalang kredensyal, patakaran sa sertipiko o bersyon ng aplikasyon, at ang client na hindi pinapansin ang weight ay kumokonekta pa rin, wala lang ang inaasahang balanse. Kailangan ng target ng sarili nitong address record, at dapat itong kanonikal na pangalan at hindi alias. Ang paglathala ng record na tumuturo sa host na walang tagapakinig ay gumagawa ng error sa koneksyon na mababasa na parang sira ng DNS, at iyon ang pinakamahal na uri ng panlilinlang. Ilathala ang buong chain o wala ni isa.

Hanapin ang label na talagang ipinapadala ng client

Itakda ang label mula sa ebidensya at hindi sa haka-haka tungkol sa pangalan ng produkto. Alinman sa sinasabi ng dokumentasyon ang pangalan ng serbisyo, o may capture na nagpapakita ng query na lumalabas sa client kapag nagsimula ito. Parehong dulo ng dalawang landas sa isang lugar: eksaktong pangalan at uri na susubukan laban sa resolver.

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

Ihambing ang sagot sa record na inilathala mo, titik sa titik, dahil bahagi ng pangalan ang mga underscore at ang tuldok sa dulo. Ang walang laman na sagot sa query na talagang ipinadala ay tumuturo sa zone, samantalang ang ganap na kawalan ng query ay tumuturo sa client, at ang mga natuklasang iyon ay nagpapadala sa iyo sa magkaibang team. Ang tunay na sagot ay mukhang ang linya sa ibaba, kung saan natatalo ang priority 20 sa alinmang record na mas mababa ang priority at idinidial ng client ang port 8443 sa pinangalanang target.

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

Dapat ding umiral ang target

Ang target na naresolba ay hindi katulad ng serbisyong sumasagot. Suriin ang address record ng target, pagkatapos ay suriin na may nakikinig sa inilathalang port at protocol. Ang TCP record na tumuturo sa tagapakinig na UDP lamang ay hindi pagkakatugma na hindi kayang ayusin ng anumang pag-edit ng zone. Panatilihing maikli ang TTL habang gumagalaw ang target, at pahabain ito kapag tumigil na ang paggalaw ng pangalan.

Ang mga client na talagang nagpapatupad ng pagtuklas ay nagkakaiba sa kung gaano karami sa record ang iginagalang nila. Ang ilan ay priority lamang ang ginagamit, ang iba ay itinuturing na payo ang weight, at ang ilan ay hindi pinapansin ang port at ipinapalagay ang default. Ang mga pagkakaibang iyon ay kabilang sa iyong mga tala sa tabi ng label, dahil ipinapaliwanag nila ang pag-uugaling mukhang sira ng resolver.

Ang pagtuklas ay hindi pagpapatotoo

Sinasabi ng sagot ng SRV kung saan kokonekta, at wala itong sinasabi tungkol sa kung kanino magtitiwala kapag nakarating na. Iwanan ang pagpapatunay ng sertipiko at mga pagsusuri ng pagkakakilanlan ng server sa client nang eksakto tulad ng dati, dahil ang record na maaaring palsipikahin ng iba ay hindi dapat maging desisyon ng pagtitiwala. Ang mga sagot ng DNS ay maaaring i-cache at i-edit ng sinumang kumokontrol sa zone, na ginagawa silang masamang lugar upang i-encode ang patakaran.

Para sa client na walang suporta sa pagtuklas, ipamahagi ang profile o URL ng gateway na tinatanggap nito, at itala kung aling produkto ang gumagamit ng aling paraan. Ang talang iyon ay pumipigil sa susunod na administrador na magdagdag ng record at umasang gagana ito saanman. Ang spec ng SRV ay naglalarawan ng pagpili sa mga target, at ang pagbasa nito bilang mekanismo ng awtorisasyon ang paraan ng pagiging palagay ng seguridad ng isang kapaki-pakinabang na record. Ilathala nang sadya, pangalanan ang label sa iyong dokumentasyon, at ituring ang client bilang ang bahaging nagpapasya kung may kahalagahan ang lahat ng ito.