Waarom ’n SRV-rekord net ’n kliënt help wat dit self opvra

Om ’n SRV-rekord by jou sone te voeg, leer geen VPN-kliënt om dit op te soek nie. Die kliënt moet die etiket ken, besluit om die navraag te stuur en op die antwoord reageer, en DNS kan nie die eerste twee daarvan verskaf nie. Die meeste mislukte SRV-planne is dus kliëntprobleme in ’n DNS-kostuum. Lees eers die kliënt se ontdekkingsgedrag en publiseer dan net die etiket wat hy werklik opvra.

’n Rekord wat niemand navraag nie, kan niemand help

SRV publiseer die ligging van ’n diens; dit kondig nie een aan nie. Niks stoot ’n rekord na ’n kliënt nie, en geen oplosser bied ’n naam aan wat nooit gevra is nie. Die opsoek begin wanneer die toepassing besluit om dit te doen, so die etiket moet uit die produk se dokumentasie kom of uit die waarneming van die sagteware op die draad. Waar die kliënt geen ontdekkingsstap het nie, verander ’n rekord die sone en niks anders nie.

Dit is waarom een produk op ’n netwerk kan begin werk terwyl ’n ander deur dieselfde verandering onaangeraak bly. Die veranderlike is die sagteware, en die DNS-bediener doen presies wat hom gesê is. Lees ook die sone terug ná die wysiging, want ’n verkeerd getikte etiket verberg maklik tussen rekords wat almal dieselfde lyk.

Lees die velde voordat jy dit skryf

’n Rekord dra vier waardes, en elkeen antwoord ’n ander vraag: prioriteit orden die teikens wat ’n kliënt kan probeer, gewig deel die las tussen teikens van gelyke prioriteit, poort benoem die vervoerpoort, en teiken benoem die gasheer. Die spesifikasie laat ook ’n teiken van . toe om te beteken dat die diens doelbewus onbeskikbaar is, wat ’n nuttige antwoord is eerder as ’n gebreekte een.

Geen van daardie velde dra geloofsbriewe, ’n sertifikaatbeleid of ’n toepassingsweergawe nie, en ’n kliënt wat gewig ignoreer, maak steeds verbinding, net sonder die beoogde balans. Die teiken het sy eie adresrekords nodig, en dit moet ’n kanonieke naam wees eerder as ’n alias. Om ’n rekord te publiseer wat na ’n gasheer sonder ’n luisteraar wys, lewer ’n verbindingsfout wat soos ’n DNS-fout lees, wat die duurste soort misleiding is. Publiseer die hele ketting of niks daarvan nie.

Vind die etiket wat die kliënt werklik stuur

Stel die etiket uit bewyse vas eerder as uit ’n raaiskoot oor die produk se naam. Óf die dokumentasie noem die diensnaam, óf ’n opname wys die navraag wat die kliënt verlaat wanneer dit begin. Beide roetes eindig op dieselfde plek: ’n presiese naam en tipe om teen die oplosser te toets.

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

Vergelyk die antwoord met die rekord wat jy gepubliseer het, karakter vir karakter, want die onderstrepings en die punt aan die einde is deel van die naam. ’n Leë antwoord op ’n navraag wat werklik gestuur is, wys na die sone, terwyl geen navraag hoegenaamd na die kliënt wys, en daardie bevindings stuur jou na verskillende spanne. ’n Ware antwoord lyk soos die reël hieronder, waar prioriteit 20 teen enige rekord met laer prioriteit verloor en die kliënt poort 8443 op die genoemde teiken skakel.

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

Die teiken moet ook bestaan

’n Teiken wat oplos, is nie dieselfde as ’n diens wat antwoord nie. Kontroleer die adresrekords vir die teiken en kontroleer dan dat iets op die gepubliseerde poort en protokol luister. ’n TCP-rekord wat na ’n slegs-UDP-luisteraar wys, is ’n wanverhouding wat geen hoeveelheid sone-redigering herstel nie. Hou die TTL kort terwyl die teiken in beweging is, en verleng dit sodra die naam ophou beweeg.

Kliënte wat wel ontdekking implementeer, verskil in hoeveel van die rekord hulle eerbiedig. Sommige gebruik net prioriteit, sommige behandel gewig as ’n aanbeveling, en ’n paar ignoreer die poort en aanvaar ’n verstekwaarde. Daardie verskille hoort in jou notas langs die etiket, want hulle verduidelik gedrag wat andersins soos ’n oplosserfout lyk.

Ontdekking is nie outentisering nie

’n SRV-antwoord sê waar om te verbind, en dit sê niks oor wie om te vertrou sodra jy daar aankom. Hou die kliënt se sertifikaatvalidering en bediener-identiteitskontroles presies soos hulle was, want ’n rekord wat iemand anders kan vervals, moenie ’n vertrouensbesluit word nie. DNS-antwoorde kan gekas en gewysig word deur wie ook al die sone beheer, wat hulle ’n swak plek maak om beleid te kodifiseer.

Vir ’n kliënt sonder ontdekkingsondersteuning, versprei die profiel of poortweg-URL wat dit wel aanvaar, en teken aan watter produk watter metode gebruik. Daardie nota keer dat die volgende administrateur ’n rekord byvoeg en verwag dat dit oral sal werk. Die SRV-spesifikasie beskryf seleksie tussen teikens, en om dit as ’n magtigingsmeganisme te lees, is hoe ’n nuttige rekord ’n sekuriteitsaanname word. Publiseer doelbewus, noem die etiket in jou dokumentasie, en behandel die kliënt as die komponent wat besluit of enigiets daarvan saak maak.