Kial SRV-rikordo helpas nur klienton, kiu mem demandas ĝin

Aldoni SRV-rikordon al via zono ne instruas ajnan VPN-klienton serĉi ĝin. La kliento devas koni la etikedon, decidi sendi la demandon kaj agi laŭ tio, kio revenas, kaj DNS ne povas provizi la unuajn du el tiuj. Tial la plej multaj malsukcesaj SRV-planoj estas klientaj problemoj en DNS-kostumo. Legu unue la konduton de la kliento pri malkovrado, poste publikigu nur la etikedon, kiun ĝi efektive demandas.

Rikordo, kiun neniu demandas, povas helpi neniun

SRV publikigas la lokon de servo; ĝi ne anoncas ĝin. Nenio puŝas rikordon al kliento, kaj neniu solvilo proponas nomon, kiun oni neniam demandis. La serĉo komenciĝas kiam la aplikaĵo decidas fari ĝin, do la etikedo devas veni el la dokumentaro de la produkto aŭ el observado de la programaro en la reto. Kie la kliento havas neniun paŝon de malkovrado, rikordo ŝanĝas la zonon kaj nenion alian.

Tial unu produkto en reto povas komenci funkcii dum alia ne estas tuŝita de la sama ŝanĝo. La variablo estas la programaro, kaj la DNS-servilo faras precize tion, kion oni diris al ĝi. Relutu la zonon ankaŭ post la redakto, ĉar mistajpita etikedo facile kaŝiĝas inter rikordoj, kiuj ĉiuj aspektas samaj.

Legu la kampojn antaŭ ol skribi ilin

Rikordo portas kvar valorojn, kaj ĉiu respondas al malsama demando: prioritato ordigas la celojn, kiujn kliento povas provi, pezo dividas la ŝarĝon inter celoj de egala prioritato, pordo nomas la transportan pordon, kaj celo nomas la gastiganton. La specifiko ankaŭ permesas celon . por signifi, ke la servo estas intence neatingebla, kio estas utila respondo kaj ne difektita.

Neniu el tiuj kampoj portas akreditaĵojn, atestilan politikon aŭ aplikajan version, kaj kliento, kiu ignoras pezon, ankoraŭ konektiĝas, nur sen la celita ekvilibro. La celo bezonas proprajn adresajn rikordojn, kaj ĝi devus esti kanonika nomo anstataŭ kaŝnomo. Publikigi rikordon, kiu montras al gastiganto sen aŭskultanto, kreas konektan eraron, kiu legiĝas kiel DNS-difekto, kaj tio estas la plej multekosta speco de misgvidado. Publikigu la tutan ĉenon aŭ nenion el ĝi.

Trovu la etikedon, kiun la kliento efektive sendas

Establu la etikedon el pruvoj anstataŭ el konjekto pri la nomo de la produkto. Aŭ la dokumentaro nomas la servon, aŭ kaptaĵo montras la demandon forlasantan la klienton ĉe starto. Ambaŭ vojoj finiĝas samloke: preciza nomo kaj tipo por testi kontraŭ la solvilo.

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

Komparu la respondon kun la rikordo, kiun vi publikigis, signon post signo, ĉar la substrekoj kaj la fina punkto estas parto de la nomo. Malplena respondo al demando, kiu efektive estis sendita, montras al la zono, dum tute nenia demando montras al la kliento, kaj tiuj trovaĵoj sendas vin al malsamaj teamoj. Reala respondo aspektas kiel la suba linio, kie prioritato 20 malgajnas kontraŭ ajna rikordo de pli malalta prioritato kaj la kliento vokas pordon 8443 ĉe la nomita celo.

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

La celo ankaŭ devas ekzisti

Celo, kiu solviĝas, ne estas la sama kiel servo, kiu respondas. Kontrolu la adresajn rikordojn por la celo, poste kontrolu, ke io aŭskultas sur la publikigita pordo kaj protokolo. TCP-rikordo montranta al aŭskultanto nur UDP estas miskongruo, kiun neniu zona redakto riparas. Tenu la TTL mallongan dum la celo estas ŝanĝiĝema, kaj longigu ĝin kiam la nomo ĉesas moviĝi.

Klientoj, kiuj efektive realigas malkovradon, varias laŭ kiom da la rikordo ili respektas. Kelkaj uzas nur prioritaton, kelkaj traktas pezon kiel konsilon, kaj kelkaj ignoras la pordon kaj supozas defaŭlton. Tiuj diferencoj apartenas al viaj notoj apud la etikedo, ĉar ili klarigas konduton, kiu alie aspektas kiel difekto de la solvilo.

Malkovrado ne estas aŭtentikigo

SRV-respondo diras, kie konektiĝi, kaj ĝi diras nenion pri tio, kiun fidi post alveno. Tenu la atestilan validigon kaj la servidentecajn kontrolojn de la kliento precize kiel ili estis, ĉar rikordo, kiun iu alia povas falsigi, ne devus fariĝi decido pri fido. DNS-respondoj estas kaŝeblaj kaj redakteblaj de kiu ajn regas la zonon, kio igas ilin malbona loko por enkodi politikon.

Por kliento sen malkovrada subteno, disdonu la profilon aŭ pordegan URL-on, kiun ĝi akceptas, kaj notu, kiu produkto uzas kiun metodon. Tiu noto malhelpas la sekvan administranton aldoni rikordon kaj atendi, ke ĝi funkcios ĉie. La SRV-specifiko priskribas elekton inter celoj, kaj legi ĝin kiel rajtigan mekanismon estas la maniero, kiel utila rikordo fariĝas sekureca supozo. Publikigu intence, nomu la etikedon en via dokumentaro, kaj traktu la klienton kiel la komponanton, kiu decidas, ĉu io el tio gravas.