Varför en SRV-post bara hjälper en klient som själv slår upp den

Att lägga till en SRV-post i din zon lär ingen VPN-klient att slå upp den. Klienten måste känna till etiketten, besluta sig för att skicka frågan och agera på det som kommer tillbaka, och DNS kan inte leverera de två första. Därför är de flesta misslyckade SRV-planer klientproblem i DNS-kostym. Läs klientens upptäcktsbeteende först och publicera sedan bara den etikett som den faktiskt frågar efter.

En post som ingen slår upp kan inte hjälpa någon

SRV publicerar en tjänsts placering; den annonserar den inte. Ingenting skjuter en post mot en klient, och ingen resolver erbjuder ett namn som aldrig efterfrågades. Uppslaget börjar när applikationen bestämmer sig för att göra det, så etiketten måste komma från produktens dokumentation eller från att observera programvaran i nätet. Där klienten inte har något upptäcktssteg ändrar en post zonen och ingenting annat.

Därför kan en produkt i ett nät börja fungera medan en annan inte påverkas av samma ändring. Variabeln är programvaran, och DNS-servern gör exakt det den blev tillsagd. Läs zonen igen efter redigeringen, eftersom en felstavad etikett lätt gömmer sig bland poster som alla ser likadana ut.

Läs fälten innan du skriver dem

En post bär fyra värden, och varje värde svarar på en annan fråga: prioritet ordnar målen som en klient kan prova, vikt fördelar lasten mellan mål med samma prioritet, port anger transportporten och mål anger värden. Specifikationen tillåter också ett mål på . för att betyda att tjänsten medvetet inte är tillgänglig, vilket är ett användbart svar och inte ett trasigt.

Inget av dessa fält bär inloggningsuppgifter, en certifikatpolicy eller en applikationsversion, och en klient som ignorerar vikt ansluter ändå, bara utan den avsedda balansen. Målet behöver egna adressposter, och det bör vara ett kanoniskt namn och inte ett alias. Att publicera en post som pekar på en värd utan lyssnare ger ett anslutningsfel som läses som ett DNS-fel, och det är den dyraste formen av vilseledning. Publicera hela kedjan eller ingenting av den.

Hitta den etikett som klienten faktiskt skickar

Fastställ etiketten utifrån bevis i stället för en gissning om produktens namn. Antingen anger dokumentationen tjänstens namn, eller så visar en inspelning den fråga som lämnar klienten när den startar. Båda vägarna slutar på samma ställe: ett exakt namn och en typ att testa mot resolvern.

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

Jämför svaret med posten du publicerade, tecken för tecken, eftersom understrykningarna och punkten i slutet är en del av namnet. Ett tomt svar på en fråga som faktiskt skickades pekar på zonen, medan ingen fråga alls pekar på klienten, och de fynden skickar dig till olika team. Ett riktigt svar ser ut som raden nedan, där prioritet 20 förlorar mot varje post med lägre prioritet och klienten ringer port 8443 på det namngivna målet.

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

Målet måste också finnas

Ett mål som löses upp är inte samma sak som en tjänst som svarar. Kontrollera adressposterna för målet och kontrollera sedan att något lyssnar på den publicerade porten och protokollet. En TCP-post som pekar på en lyssnare som bara är UDP är en brist som ingen zonändring reparerar. Håll TTL kort medan målet är i rörelse, och förläng det när namnet slutar flytta sig.

Klienter som faktiskt implementerar upptäckt varierar i hur mycket av posten de respekterar. Några använder bara prioritet, några behandlar vikt som rådgivande, och ett fåtal ignorerar porten och antar ett standardvärde. De skillnaderna hör hemma i dina anteckningar bredvid etiketten, eftersom de förklarar beteende som annars ser ut som ett resolverfel.

Upptäckt är inte autentisering

Ett SRV-svar säger var du ska ansluta, och det säger ingenting om vem du ska lita på när du kommer fram. Låt klientens certifikatvalidering och serveridentitetskontroller vara exakt som de var, eftersom en post som någon annan kan förfalska inte bör bli ett förtroendebeslut. DNS-svar kan cachas och redigeras av den som kontrollerar zonen, vilket gör dem till en dålig plats att koda policy i.

För en klient utan stöd för upptäckt, distribuera profilen eller gateway-URL:en som den accepterar, och notera vilken produkt som använder vilken metod. Den anteckningen hindrar nästa administratör från att lägga till en post och förvänta sig att den fungerar överallt. SRV-specifikationen beskriver valet mellan mål, och att läsa den som en auktoriseringsmekanism är hur en användbar post blir ett säkerhetsantagande. Publicera medvetet, namnge etiketten i din dokumentation och behandla klienten som den komponent som avgör om något av detta spelar roll.