Prečo SRV záznam pomôže len klientovi, ktorý sa naň pýta sám

Pridanie SRV záznamu do vašej zóny nenaučí žiadneho klienta VPN, aby ho hľadal. Klient musí poznať značku, rozhodnúť sa odoslať dotaz a konať podľa toho, čo sa vráti, a DNS nemôže zabezpečiť prvé dve z toho. Preto je väčšina neúspešných plánov SRV klientskym problémom v kostýme DNS. Najprv si prečítajte správanie klienta pri objavovaní a potom zverejnite iba tú značku, na ktorú sa skutočne pýta.

Záznam, na ktorý sa nikto nepýta, nikomu nepomôže

SRV zverejňuje umiestnenie služby; neoznamuje ju. Nič netlačí záznam ku klientovi a žiadny resolver neponúka meno, na ktoré sa nikdy nepýtali. Vyhľadávanie sa začína, keď sa aplikácia rozhodne ho vykonať, takže značka musí pochádzať z dokumentácie produktu alebo z pozorovania softvéru v sieti. Kde klient nemá krok objavovania, záznam zmení zónu a nič iné.

Preto môže jeden produkt v sieti začať fungovať, zatiaľ čo iný tou istou zmenou nie je zasiahnutý. Premennou je softvér a server DNS robí presne to, čo mu bolo povedané. Po úprave si zónu prečítajte znova, pretože preklep v značke sa ľahko skryje medzi záznamami, ktoré vyzerajú všetky rovnako.

Prečítajte si polia, kým ich zapíšete

Záznam nesie štyri hodnoty a každá odpovedá na inú otázku: priorita zoraďuje ciele, ktoré môže klient vyskúšať, váha delí záťaž medzi ciele rovnakej priority, port pomenúva transportný port a cieľ pomenúva hostiteľa. Špecifikácia tiež pripúšťa cieľ . s významom, že služba je zámerne nedostupná, čo je užitočná odpoveď, nie pokazená.

Žiadne z týchto polí nenesie prihlasovacie údaje, politiku certifikátov ani verziu aplikácie, a klient, ktorý ignoruje váhu, sa aj tak pripojí, len bez zamýšľanej rovnováhy. Cieľ potrebuje vlastné adresové záznamy a mal by byť kanonické meno, nie alias. Zverejnenie záznamu, ktorý ukazuje na hostiteľa bez poslucháča, vytvára chybu pripojenia, ktorá sa číta ako porucha DNS, a to je najdrahší druh zavádzania. Zverejnite celú reťaz alebo nič z nej.

Nájdite značku, ktorú klient skutočne posiela

Určte značku z dôkazov, nie z odhadu názvu produktu. Buď dokumentácia uvádza názov služby, alebo záznam prevádzky ukáže dotaz, ktorý pri spustení odchádza z klienta. Obe cesty končia na tom istom mieste: presný názov a typ na otestovanie voči resolveru.

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

Porovnajte odpoveď so záznamom, ktorý ste zverejnili, znak po znaku, pretože podčiarkovníky a bodka na konci sú súčasťou názvu. Prázdna odpoveď na dotaz, ktorý sa skutočne odoslal, ukazuje na zónu, kým úplná neprítomnosť dotazu ukazuje na klienta, a tieto zistenia vás pošlú k rôznym tímom. Skutočná odpoveď vyzerá ako riadok nižšie, kde priorita 20 prehráva s každým záznamom nižšej priority a klient vytočí port 8443 na uvedenom cieli.

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

Cieľ musí tiež existovať

Cieľ, ktorý sa preloží, nie je to isté ako služba, ktorá odpovedá. Skontrolujte adresové záznamy cieľa a potom skontrolujte, či na zverejnenom porte a protokole niečo načúva. TCP záznam ukazujúci na poslucháča iba UDP je nesúlad, ktorý žiadna úprava zóny nenapraví. Kým je cieľ v pohybe, držte TTL krátke, a predĺžte ho, keď sa názov prestane hýbať.

Klienti, ktorí objavovanie skutočne implementujú, sa líšia v tom, akú časť záznamu rešpektujú. Niektorí používajú iba prioritu, iní berú váhu ako odporúčanie a zopár ignoruje port a predpokladá predvolenú hodnotu. Tieto rozdiely patria do vašich poznámok vedľa značky, pretože vysvetľujú správanie, ktoré inak vyzerá ako porucha resolvera.

Objavovanie nie je autentifikácia

Odpoveď SRV hovorí, kam sa pripojiť, a nehovorí nič o tom, komu veriť po príchode. Nechajte validáciu certifikátu a kontroly identity servera v klientovi presne také, aké boli, pretože záznam, ktorý môže niekto iný sfalšovať, by sa nemal stať rozhodnutím o dôvere. Odpovede DNS sa dajú ukladať do vyrovnávacej pamäte a upravovať tým, kto ovláda zónu, čo z nich robí zlé miesto na kódovanie politiky.

Pre klienta bez podpory objavovania distribuujte profil alebo URL brány, ktorú prijíma, a poznamenajte si, ktorý produkt používa ktorú metódu. Táto poznámka zabráni ďalšiemu správcovi pridať záznam a očakávať, že bude fungovať všade. Špecifikácia SRV opisuje výber medzi cieľmi a čítať ju ako autorizačný mechanizmus je cesta, ako sa užitočný záznam stane bezpečnostným predpokladom. Zverejňujte vedome, pomenujte značku vo svojej dokumentácii a ku klientovi pristupujte ako ku komponente, ktorá rozhoduje, či na tom všetkom záleží.