De ce o înregistrare SRV ajută doar un client care o interoghează singur

Adăugarea unei înregistrări SRV în zonă nu învață niciun client VPN să o caute. Clientul trebuie să cunoască eticheta, să decidă să trimită interogarea și să acționeze în funcție de ce revine, iar DNS nu poate furniza primele două. De aceea majoritatea planurilor SRV eșuate sunt probleme de client îmbrăcate în DNS. Citiți mai întâi comportamentul de descoperire al clientului, apoi publicați doar eticheta pe care o interoghează efectiv.

O înregistrare pe care nimeni nu o interoghează nu poate ajuta pe nimeni

SRV publică locația unui serviciu; nu îl anunță. Nimic nu împinge o înregistrare spre un client și niciun resolver nu oferă un nume care nu a fost cerut vreodată. Căutarea începe când aplicația decide să o facă, așa că eticheta trebuie să vină din documentația produsului sau din observarea software-ului în rețea. Acolo unde clientul nu are niciun pas de descoperire, o înregistrare schimbă zona și nimic altceva.

De aceea un produs dintr-o rețea poate începe să funcționeze în timp ce altul nu este afectat de aceeași schimbare. Variabila este software-ul, iar serverul DNS face exact ce i s-a spus. Recitiți zona după editare, pentru că o etichetă scrisă greșit se ascunde ușor printre înregistrări care arată toate la fel.

Citiți câmpurile înainte de a le scrie

O înregistrare poartă patru valori, iar fiecare răspunde la o întrebare diferită: prioritatea ordonează țintele pe care clientul le poate încerca, ponderea împarte sarcina între ținte de aceeași prioritate, portul numește portul de transport, iar ținta numește gazda. Specificația permite și o țintă de . pentru a însemna că serviciul este deliberat indisponibil, ceea ce este un răspuns util și nu unul stricat.

Niciunul dintre aceste câmpuri nu poartă acreditări, o politică de certificate sau o versiune a aplicației, iar un client care ignoră ponderea se conectează totuși, doar fără echilibrul dorit. Ținta are nevoie de propriile înregistrări de adresă și ar trebui să fie un nume canonic, nu un alias. Publicarea unei înregistrări care indică o gazdă fără receptor produce o eroare de conectare care se citește ca o defecțiune DNS, iar acesta este cel mai costisitor tip de inducere în eroare. Publicați întregul lanț sau nimic din el.

Găsiți eticheta pe care clientul o trimite efectiv

Stabiliți eticheta pe baza dovezilor, nu a unei presupuneri despre numele produsului. Fie documentația indică numele serviciului, fie o captură arată interogarea care pleacă din client la pornire. Ambele căi se termină în același loc: un nume și un tip exacte de testat împotriva resolverului.

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

Comparați răspunsul cu înregistrarea publicată, caracter cu caracter, pentru că sublinierile și punctul final fac parte din nume. Un răspuns gol la o interogare trimisă efectiv indică zona, în timp ce absența totală a interogării indică clientul, iar aceste constatări vă trimit la echipe diferite. Un răspuns real arată ca linia de mai jos, unde prioritatea 20 pierde în fața oricărei înregistrări cu prioritate mai mică, iar clientul formează portul 8443 pe ținta indicată.

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

Ținta trebuie să existe și ea

O țintă care se rezolvă nu este același lucru cu un serviciu care răspunde. Verificați înregistrările de adresă ale țintei, apoi verificați că ceva ascultă pe portul și protocolul publicate. O înregistrare TCP care indică un receptor doar UDP este o nepotrivire pe care nicio editare a zonei nu o repară. Păstrați TTL-ul scurt cât timp ținta este în mișcare și prelungiți-l când numele nu se mai mișcă.

Clienții care implementează într-adevăr descoperirea diferă în cât din înregistrare respectă. Unii folosesc doar prioritatea, alții tratează ponderea ca sfat, iar câțiva ignoră portul și presupun o valoare implicită. Aceste diferențe aparțin notițelor dumneavoastră lângă etichetă, pentru că explică un comportament care altfel pare o defecțiune a resolverului.

Descoperirea nu este autentificare

Un răspuns SRV spune unde să vă conectați, iar nu spune nimic despre în cine să aveți încredere după ce ajungeți. Lăsați validarea certificatului și verificările de identitate ale serverului din client exact cum erau, pentru că o înregistrare pe care altcineva o poate falsifica nu ar trebui să devină o decizie de încredere. Răspunsurile DNS pot fi stocate în cache și editate de oricine controlează zona, ceea ce le face un loc prost pentru codificarea politicilor.

Pentru un client fără suport de descoperire, distribuiți profilul sau URL-ul de gateway pe care îl acceptă și notați ce produs folosește ce metodă. Acea notă împiedică următorul administrator să adauge o înregistrare și să se aștepte să funcționeze peste tot. Specificația SRV descrie selecția între ținte, iar citirea ei ca mecanism de autorizare este modul în care o înregistrare utilă devine o presupunere de securitate. Publicați deliberat, numiți eticheta în documentația dumneavoastră și tratați clientul ca componenta care decide dacă toate acestea contează.