Waarom een SRV-record alleen een client helpt die het zelf opvraagt

Een SRV-record aan uw zone toevoegen leert geen enkele VPN-client om het op te zoeken. De client moet het label kennen, beslissen de query te versturen en handelen naar wat er terugkomt, en DNS kan de eerste twee daarvan niet leveren. Daarom zijn de meeste mislukte SRV-plannen clientproblemen in een DNS-kostuum. Lees eerst het ontdekkingsgedrag van de client en publiceer daarna alleen het label dat hij werkelijk opvraagt.

Een record dat niemand opvraagt, kan niemand helpen

SRV publiceert de locatie van een dienst; het kondigt die niet aan. Niets duwt een record naar een client toe, en geen resolver biedt een naam aan waar nooit naar gevraagd is. De opzoeking begint wanneer de toepassing besluit die te doen, dus het label moet uit de productdocumentatie komen of uit het observeren van de software op het netwerk. Waar de client geen ontdekkingsstap heeft, verandert een record de zone en niets anders.

Daarom kan het ene product op een netwerk gaan werken terwijl het andere niet door dezelfde wijziging wordt geraakt. De variabele is de software, en de DNS-server doet precies wat hem is gezegd. Lees de zone na de wijziging ook terug, want een verkeerd getypt label verstopt zich makkelijk tussen records die er allemaal hetzelfde uitzien.

Lees de velden voordat u ze schrijft

Een record draagt vier waarden, en elk beantwoordt een andere vraag: prioriteit ordent de doelen die een client mag proberen, gewicht verdeelt de belasting tussen doelen met gelijke prioriteit, poort benoemt de transportpoort, en doel benoemt de host. De specificatie staat ook een doel van . toe om te betekenen dat de dienst opzettelijk niet beschikbaar is, wat een nuttig antwoord is en geen kapot.

Geen van die velden draagt inloggegevens, een certificaatbeleid of een applicatieversie, en een client die gewicht negeert, verbindt nog steeds, alleen zonder de bedoelde balans. Het doel heeft eigen adresrecords nodig, en het zou een canonieke naam moeten zijn en geen alias. Een record publiceren dat naar een host zonder luisteraar wijst, levert een verbindingsfout op die als een DNS-fout leest, en dat is de duurste vorm van misleiding. Publiceer de hele keten of niets ervan.

Vind het label dat de client werkelijk stuurt

Stel het label vast op basis van bewijs en niet van een gok over de productnaam. Ofwel noemt de documentatie de dienstnaam, ofwel toont een opname de query die de client bij het starten verlaat. Beide routes eindigen op dezelfde plek: een exacte naam en type om tegen de resolver te testen.

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

Vergelijk het antwoord teken voor teken met het record dat u hebt gepubliceerd, want de underscores en de punt aan het eind horen bij de naam. Een leeg antwoord op een query die werkelijk is verzonden wijst op de zone, terwijl helemaal geen query op de client wijst, en die bevindingen sturen u naar verschillende teams. Een echt antwoord ziet eruit als de regel hieronder, waar prioriteit 20 verliest van elk record met lagere prioriteit en de client poort 8443 op het genoemde doel kiest.

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

Het doel moet ook bestaan

Een doel dat oplost is niet hetzelfde als een dienst die antwoordt. Controleer de adresrecords voor het doel en controleer daarna of er iets luistert op de gepubliceerde poort en het protocol. Een TCP-record dat naar een luisteraar wijst die alleen UDP is, is een mismatch die geen zonebewerking repareert. Houd de TTL kort zolang het doel in beweging is, en verleng hem wanneer de naam ophoudt te bewegen.

Clients die ontdekking wel implementeren, verschillen in hoeveel van het record ze respecteren. Sommige gebruiken alleen prioriteit, sommige behandelen gewicht als advies, en een paar negeren de poort en nemen een standaard aan. Die verschillen horen in uw notities naast het label, want ze verklaren gedrag dat er anders als een resolverfout uitziet.

Ontdekking is geen authenticatie

Een SRV-antwoord zegt waar u verbinding moet maken, en het zegt niets over wie u moet vertrouwen als u aankomt. Laat de certificaatvalidatie en de identiteitscontroles van de server bij de client precies zoals ze waren, want een record dat iemand anders kan vervalsen, mag geen vertrouwensbeslissing worden. DNS-antwoorden kunnen worden gecachet en bewerkt door wie de zone beheert, wat ze een slechte plek maakt om beleid in te coderen.

Voor een client zonder ondersteuning voor ontdekking, verspreid het profiel of de gateway-URL die hij wel accepteert, en noteer welk product welke methode gebruikt. Die notitie weerhoudt de volgende beheerder ervan een record toe te voegen en te verwachten dat het overal werkt. De SRV-specificatie beschrijft de selectie tussen doelen, en die als autorisatiemechanisme lezen is de manier waarop een nuttig record een beveiligingsaanname wordt. Publiceer bewust, benoem het label in uw documentatie, en behandel de client als het onderdeel dat beslist of dit alles betekenis heeft.