Pse një regjistrim SRV ndihmon vetëm një klient që e pyet vetë

Shtimi i një regjistrimi SRV në zonën tuaj nuk mëson asnjë klient VPN ta kërkojë atë. Klienti duhet ta dijë etiketën, të vendosë ta dërgojë pyetjen dhe të veprojë sipas asaj që kthehet, dhe DNS nuk mund të sigurojë dy të parat. Prandaj shumica e planeve SRV të dështuara janë probleme klienti të veshura si DNS. Lexoni së pari sjelljen e zbulimit të klientit dhe pastaj publikoni vetëm etiketën që ai pyet në të vërtetë.

Një regjistrim që askush nuk e pyet nuk mund të ndihmojë askënd

SRV publikon vendndodhjen e një shërbimi; nuk e shpall atë. Asgjë nuk e shtyn një regjistrim drejt një klienti, dhe asnjë zgjidhës nuk ofron një emër për të cilin nuk është pyetur kurrë. Kërkimi fillon kur aplikacioni vendos ta bëjë atë, kështu që etiketa duhet të vijë nga dokumentacioni i produktit ose nga vëzhgimi i softuerit në rrjet. Aty ku klienti nuk ka asnjë hap zbulimi, një regjistrim ndryshon zonën dhe asgjë tjetër.

Kjo është arsyeja pse një produkt në një rrjet mund të fillojë të funksionojë ndërsa një tjetër nuk preket nga i njëjti ndryshim. Variabli është softueri, dhe serveri DNS bën saktësisht atë që i është thënë. Lexojeni zonën përsëri pas redaktimit, sepse një etiketë e shtypur gabim fshihet lehtë midis regjistrimeve që duken të gjithë njësoj.

Lexoni fushat përpara se t’i shkruani

Një regjistrim mbart katër vlera, dhe secila përgjigjet një pyetjeje të ndryshme: përparësia rendit objektivat që klienti mund të provojë, pesha shpërndan ngarkesën midis objektivave me të njëjtën përparësi, porta emëron portën e transportit, dhe objektivi emëron hostin. Specifikimi lejon gjithashtu një objektiv . për të nënkuptuar që shërbimi është qëllimisht i padisponueshëm, gjë që është përgjigje e dobishme dhe jo e prishur.

Asnjë nga këto fusha nuk mbart kredenciale, një politikë certifikatash ose një version aplikacioni, dhe një klient që injoron peshën lidhet gjithsesi, thjesht pa ekuilibrin e synuar. Objektivi ka nevojë për regjistrimet e veta të adresës dhe duhet të jetë emër kanonik, jo alias. Publikimi i një regjistrimi që tregon një host pa dëgjues prodhon një gabim lidhjeje që lexohet si defekt DNS, dhe ky është lloji më i shtrenjtë i mashtrimit. Publikojeni të gjithë zinxhirin ose asgjë prej tij.

Gjeni etiketën që klienti dërgon në të vërtetë

Përcaktoni etiketën nga provat dhe jo nga një supozim për emrin e produktit. Ose dokumentacioni jep emrin e shërbimit, ose një regjistrim tregon pyetjen që del nga klienti kur nis. Të dyja rrugët përfundojnë në të njëjtin vend: një emër dhe tip i saktë për t’u testuar kundrejt zgjidhësit.

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

Krahasoni përgjigjen me regjistrimin që keni publikuar, karakter për karakter, sepse nënvizat dhe pika në fund janë pjesë e emrit. Një përgjigje bosh ndaj një pyetjeje që u dërgua vërtet tregon zonën, ndërsa mungesa e plotë e pyetjes tregon klientin, dhe këto gjetje ju dërgojnë te ekipe të ndryshme. Një përgjigje e vërtetë duket si rreshti më poshtë, ku përparësia 20 humbet ndaj çdo regjistrimi me përparësi më të ulët dhe klienti thërret portën 8443 në objektivin e emërtuar.

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

Objektivi duhet të ekzistojë gjithashtu

Një objektiv që zgjidhet nuk është i njëjtë me një shërbim që përgjigjet. Kontrolloni regjistrimet e adresës për objektivin, pastaj kontrolloni që diçka dëgjon në portën dhe protokollin e publikuar. Një regjistrim TCP që tregon një dëgjues vetëm UDP është mospërputhje që asnjë redaktim zone nuk e rregullon. Mbani TTL të shkurtër sa kohë objektivi është në lëvizje, dhe zgjaseni kur emri ndalon së lëvizuri.

Klientët që e zbatojnë vërtet zbulimin ndryshojnë në atë se sa nga regjistrimi respektojnë. Disa përdorin vetëm përparësinë, disa e trajtojnë peshën si këshillë, dhe pak e injorojnë portën dhe supozojnë një vlerë të paracaktuar. Këto dallime i takojnë shënimeve tuaja pranë etiketës, sepse shpjegojnë sjellje që ndryshe duket si defekt i zgjidhësit.

Zbulimi nuk është vërtetim

Një përgjigje SRV thotë ku të lidheni, dhe nuk thotë asgjë për kë të besoni pasi të mbërrini. Lërini vërtetimin e certifikatës dhe kontrollet e identitetit të serverit te klienti saktësisht siç ishin, sepse një regjistrim që dikush tjetër mund ta falsifikojë nuk duhet të bëhet vendim besimi. Përgjigjet DNS mund të ruhen në cache dhe t’i redaktojë kushdo që kontrollon zonën, gjë që i bën ato vend i keq për të kodifikuar politika.

Për një klient pa mbështetje zbulimi, shpërndani profilin ose URL-në e portës që pranon, dhe shënoni cili produkt përdor cilën metodë. Ai shënim e pengon administratorin tjetër të shtojë një regjistrim dhe të presë që të funksionojë kudo. Specifikimi SRV përshkruan zgjedhjen midis objektivave, dhe leximi i tij si mekanizëm autorizimi është mënyra se si një regjistrim i dobishëm bëhet supozim sigurie. Publikoni me qëllim, emërtoni etiketën në dokumentacionin tuaj, dhe trajtojeni klientin si komponentin që vendos nëse ndonjë nga këto ka rëndësi.