Kodėl SRV įrašas padeda tik tam klientui, kuris pats jo klausia

SRV įrašo pridėjimas prie jūsų zonos neišmoko nė vieno VPN kliento jo ieškoti. Klientas turi žinoti etiketę, nuspręsti išsiųsti užklausą ir veikti pagal tai, kas grįžta, o DNS negali užtikrinti pirmųjų dviejų dalykų. Todėl dauguma nepavykusių SRV planų yra kliento problemos DNS kostiumu. Pirmiausia perskaitykite kliento aptikimo elgseną, tada paskelbkite tik tą etiketę, kurios jis iš tikrųjų klausia.

Įrašas, kurio niekas neklausia, niekam negali padėti

SRV skelbia paslaugos vietą; jis apie ją nepraneša. Niekas nestumia įrašo link kliento, ir joks resolveris nesiūlo vardo, kurio niekada nebuvo klausta. Paieška prasideda tada, kai programa nusprendžia ją atlikti, todėl etiketė turi kilti iš produkto dokumentacijos arba iš programinės įrangos stebėjimo tinkle. Kur klientas neturi aptikimo žingsnio, įrašas pakeičia zoną ir nieko daugiau.

Štai kodėl vienas produktas tinkle gali pradėti veikti, o kitam tas pats pakeitimas neturi įtakos. Kintamasis yra programinė įranga, o DNS serveris daro būtent tai, kas jam buvo pasakyta. Perskaitykite zoną dar kartą po pakeitimo, nes neteisingai įvesta etiketė lengvai pasislepia tarp įrašų, kurie visi atrodo vienodai.

Perskaitykite laukus prieš juos rašydami

Įrašas turi keturias reikšmes, ir kiekviena atsako į skirtingą klausimą: prioritetas išdėsto tikslus, kuriuos klientas gali išbandyti, svoris paskirsto apkrovą tarp vienodo prioriteto tikslų, prievadas įvardija transporto prievadą, o tikslas įvardija mazgą. Specifikacija taip pat leidžia tikslą . reikšti, kad paslauga sąmoningai nepasiekiama, o tai naudingas atsakymas, o ne sugedęs.

Nė vienas iš šių laukų neturi prisijungimo duomenų, sertifikatų politikos ar programos versijos, o svorį ignoruojantis klientas vis tiek prisijungia, tik be numatytos pusiausvyros. Tikslas turi turėti savo adreso įrašus ir turėtų būti kanoninis vardas, o ne slapyvardis. Paskelbus įrašą, kuris rodo į mazgą be klausytojo, atsiranda ryšio klaida, kuri skaitoma kaip DNS gedimas, ir tai yra brangiausia klaidinimo rūšis. Paskelbkite visą grandinę arba nieko iš jos.

Raskite etiketę, kurią klientas iš tikrųjų siunčia

Nustatykite etiketę remdamiesi įrodymais, o ne spėjimu apie produkto pavadinimą. Arba dokumentacija nurodo paslaugos pavadinimą, arba įrašas parodo užklausą, kuri išeina iš kliento paleidimo metu. Abu keliai baigiasi toje pačioje vietoje: tikslus vardas ir tipas, kuriuos galima išbandyti su resolveriu.

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

Palyginkite atsakymą su paskelbtu įrašu po ženklą, nes pabraukimai ir taškas pabaigoje yra vardo dalis. Tuščias atsakymas į iš tikrųjų išsiųstą užklausą rodo į zoną, o visiškas užklausos nebuvimas rodo į klientą, ir šie radiniai nukreipia jus skirtingoms komandoms. Tikras atsakymas atrodo kaip eilutė žemiau, kur prioritetas 20 pralaimi bet kuriam mažesnio prioriteto įrašui ir klientas renkasi 8443 prievadą nurodytame tiksluose.

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

Tikslas taip pat turi egzistuoti

Išsprendžiamas tikslas nėra tas pats, kas atsakanti paslauga. Patikrinkite tikslo adreso įrašus, tada patikrinkite, ar kas nors klausosi paskelbtame prievade ir protokole. TCP įrašas, rodantis į tik UDP klausytoją, yra neatitikimas, kurio joks zonos redagavimas nepataiso. Laikykite TTL trumpą, kol tikslas judrus, ir pailginkite, kai vardas nustoja judėti.

Klientai, kurie iš tikrųjų įgyvendina aptikimą, skiriasi tuo, kiek įrašo jie gerbia. Kai kurie naudoja tik prioritetą, kiti traktuoja svorį kaip patarimą, o keli ignoruoja prievadą ir daro prielaidą apie numatytąją reikšmę. Tie skirtumai priklauso jūsų pastabose šalia etiketės, nes jie paaiškina elgseną, kuri kitaip atrodo kaip resolverio gedimas.

Aptikimas nėra autentifikavimas

SRV atsakymas sako, kur jungtis, ir nieko nesako apie tai, kuo pasitikėti atvykus. Palikite kliento sertifikato tikrinimą ir serverio tapatybės patikras tokius, kokie buvo, nes įrašas, kurį kas nors kitas gali suklastoti, neturėtų tapti pasitikėjimo sprendimu. DNS atsakymai gali būti saugomi podėlyje ir redaguojami bet kurio, kas valdo zoną, todėl jie yra prasta vieta politikai užkoduoti.

Klientui, kuris nepalaiko aptikimo, platinte profilį arba šliuzo URL, kurį jis priima, ir užrašykite, kuris produktas naudoja kurį metodą. Ta pastaba neleidžia kitam administratoriui pridėti įrašo ir tikėtis, kad jis veiks visur. SRV specifikacija aprašo pasirinkimą tarp tikslų, o jos skaitymas kaip autorizacijos mechanizmo yra kelias, kuriuo naudingas įrašas tampa saugumo prielaida. Skelbkite sąmoningai, įvardykite etiketę savo dokumentacijoje ir traktuokite klientą kaip komponentą, kuris nusprendžia, ar visa tai turi reikšmės.