It taheakjen fan in SRV-record oan jo sône leart gjin inkele VPN-klant om it te sykjen. De klant moat it label kenne, beslute de fraach te stjoeren en hannelje neffens wat weromkomt, en DNS kin de earste twa dêrfan net leverje. Dêrom binne de measte mislearre SRV-plannen klantproblemen yn in DNS-kostúm. Lês earst it ûntdekkingsgedrach fan ’e klant en publisearje dan allinnich it label dat er wirklik opfreget.

In record dy’t nimmen opfreget kin nimmen helpe

SRV publisearret de lokaasje fan in tsjinst; it kundiget him net oan. Neat triuwt in record nei in klant, en gjin oplosser biedt in namme oan dêr’t nea om frege is. It sykjen begjint as de applikaasje beslút it te dwaan, dus it label moat út ’e dokumintaasje fan it produkt komme of út it observearjen fan ’e software op it netwurk. Dêr’t de klant gjin ûntdekkingsstap hat, feroaret in record de sône en neat oars.

Dêrom kin ien produkt op in netwurk begjinne te wurkjen wylst in oar net troch deselde feroaring rekke wurdt. De fariabele is de software, en de DNS-tsjinjer docht krekt wat him sein is. Lês de sône ek werom nei de bewurking, want in ferkeard typte label ferberget him maklik tusken records dy’t der allegear itselde útseagen.

Lês de fjilden foardat jo se skriuwe

In record draacht fjouwer wearden, en elk beantwurdet in oare fraach: prioriteit oarderet de doelen dy’t in klant besykje kin, gewicht ferdielt de lading tusken doelen fan gelikense prioriteit, poarte neamt de ferfierspoarte, en doel neamt de host. De spesifikaasje lit ek in doel fan . ta om te betsjutten dat de tsjinst mei opsetsin net beskikber is, wat in nuttich antwurd is en net in brutsen ien.

Gjin fan dy fjilden draacht tagongsgegevens, in sertifikaatbelied of in applikaasjeferzje, en in klant dy’t gewicht negearret makket noch altyd ferbining, allinnich sûnder de bedoelde balâns. It doel hat syn eigen adresrecords nedich, en it moat in kanonike namme wêze ynstee fan in alias. It publisearjen fan in record dy’t nei in host sûnder listener wiist, jout in ferbiningsflater dy’t as in DNS-flater lêzen wurdt, en dat is de djoerste soarte fan mislieding. Publisearje de hiele keatling of neat derfan.

Fyn it label dat de klant wirklik stjoert

Stel it label fêst op grûn fan bewiis ynstee fan in gissing oer de namme fan it produkt. Of de dokumintaasje neamt de tsjinstnamme, of in opname lit de fraach sjen dy’t de klant by it starten ferlit. Beide wegen einigje op itselde plak: in krekte namme en type om tsjin de oplosser te testen.

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

Fergelykje it antwurd mei it record dat jo publisearre hawwe, teken foar teken, want de ûnderstreekjes en de punt op ’e ein binne diel fan ’e namme. In leech antwurd op in fraach dy’t wirklik stjoerd is wiist nei de sône, wylst hielendal gjin fraach nei de klant wiist, en dy befiningen stjoere jo nei ferskate teams. In echt antwurd sjocht derút as de rigel hjirûnder, dêr’t prioriteit 20 ferliest fan elk record mei legere prioriteit en de klant poarte 8443 op it neamde doel kiest.

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

It doel moat ek bestean

In doel dat oplost is net itselde as in tsjinst dy’t antwurdet. Kontrolearje de adresrecords foar it doel en kontrolearje dan dat der wat op ’e publisearre poarte en protokol harket. In TCP-record dy’t nei in listener allinnich foar UDP wiist is in mismatching dy’t gjin sônebewurking reparearret. Hâld de TTL koart salang’t it doel yn beweging is, en ferlingje him as de namme ophâldt te bewegen.

Klanten dy’t ûntdekking wol ymplementearje ferskille yn hoefolle fan it record se respektearje. Guon brûke allinnich prioriteit, guon behannelje gewicht as advys, en in pear negearje de poarte en nimme in standert oan. Dy ferskillen hearre yn jo notysjes njonken it label, want se ferklearje gedrach dat oars as in oplosserflater liket.

Untdekking is gjin autentikaasje

In SRV-antwurd seit wêr’t jo ferbine moatte, en it seit neat oer wa’t jo fertrouwe moatte as jo der oankomme. Lit de sertifikaatfalidaasje en de tsjinner-identiteitskontrôles fan ’e klant krekt sa’t se wiene, want in record dy’t in oar ferfalskje kin moat gjin fertrouwensbeslissing wurde. DNS-antwurden kinne yn ’e cache en bewurke wurde troch wa’t de sône ek mar kontrolearret, wat se in min plak makket om belied yn te kodearjen.

Foar in klant sûnder stipe foar ûntdekking, ferspriede it profyl of de gateway-URL dy’t er wol akseptearret, en notearje hokker produkt hokker metoade brûkt. Dy notysje hâldt de folgjende behearder tsjin om in record ta te heakjen en te ferwachtsjen dat it oeral wurket. De SRV-spesifikaasje beskriuwt de seleksje tusken doelen, en it lêzen dêrfan as in autorisaasjemeganisme is hoe’t in nuttich record in feiligensoanname wurdt. Publisearje mei opsetsin, neam it label yn jo dokumintaasje, en behannelje de klant as it komponint dat beslút oft it der wat ta docht.

Relatearre artikelen