Proč SRV záznam pomůže jen klientovi, který se na něj dotazuje

Přidání SRV záznamu do vaší zóny nenaučí žádného klienta VPN, aby ho hledal. Klient musí znát štítek, rozhodnout se dotaz odeslat a podle toho, co se vrátí, jednat, a DNS nemůže zajistit první dvě z těchto věcí. Většina neúspěšných plánů se SRV jsou proto klientské problémy v převleku DNS. Nejprve si přečtěte chování klienta při objevování a pak zveřejněte jen ten štítek, na který se skutečně dotazuje.

Záznam, na který se nikdo neptá, nikomu nepomůže

SRV zveřejňuje umístění služby; neoznamuje ji. Nic netlačí záznam ke klientovi a žádný resolver nenabízí jméno, na které se nikdy neptalo. Vyhledávání začíná rozhodnutím aplikace, že ho provede, takže štítek musí pocházet z dokumentace produktu nebo z pozorování softwaru v síti. Kde klient nemá krok objevování, záznam změní zónu a nic jiného.

Proto může jeden produkt v síti začít fungovat, zatímco jiný stejnou změnou není dotčen. Proměnnou je software a server DNS dělá přesně to, co mu bylo řečeno. Po úpravě si zónu také přečtěte znovu, protože překlep ve štítku se snadno schová mezi záznamy, které vypadají všechny stejně.

Přečtěte si pole, než je zapíšete

Záznam nese čtyři hodnoty a každá odpovídá na jinou otázku: priorita řadí cíle, které může klient zkusit, váha dělí zátěž mezi cíle stejné priority, port pojmenovává transportní port a cíl pojmenovává hostitele. Specifikace také připouští, aby cíl . znamenal, že služba je záměrně nedostupná, což je užitečná odpověď, ne rozbitá.

Žádné z těchto polí nenese přihlašovací údaje, politiku certifikátů ani verzi aplikace, a klient, který váhu ignoruje, se stejně připojí, jen bez zamýšleného vyvážení. Cíl potřebuje vlastní adresové záznamy a měl by to být kanonický název, ne alias. Zveřejnění záznamu, který ukazuje na hostitele bez posluchače, vytváří chybu připojení, jež se čte jako závada DNS, a to je nejdražší druh klamání. Zveřejněte celý řetěz, nebo nic z něj.

Najděte štítek, který klient skutečně posílá

Určete štítek z důkazů, ne z odhadu názvu produktu. Buď dokumentace uvádí název služby, nebo záznam provozu ukáže dotaz, který klient při spuštění vyšle. Obě cesty končí na stejném místě: přesný název a typ k otestování proti resolveru.

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

Porovnejte odpověď se záznamem, který jste zveřejnili, znak po znaku, protože podtržítka a tečka na konci jsou součástí názvu. Prázdná odpověď na dotaz, který skutečně byl odeslán, ukazuje na zónu, kdežto úplná nepřítomnost dotazu ukazuje na klienta, a tato zjištění vás pošlou k různým týmům. Skutečná odpověď vypadá jako řádek níže, kde priorita 20 prohrává s každým záznamem nižší priority a klient volá port 8443 na uvedeném cíli.

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

Cíl musí také existovat

Cíl, který se přeloží, není totéž jako služba, která odpovídá. Zkontrolujte adresové záznamy cíle a potom zkontrolujte, že na zveřejněném portu a protokolu něco naslouchá. TCP záznam ukazující na posluchače pouze UDP je nesoulad, který žádná úprava zóny nespraví. Dokud je cíl v pohybu, držte TTL krátké, a prodlužte ho, jakmile se název přestane hýbat.

Klienti, kteří objevování skutečně implementují, se liší v tom, jak velkou část záznamu respektují. Někteří používají jen prioritu, někteří berou váhu jako doporučení a pár jich ignoruje port a předpokládá výchozí hodnotu. Tyto rozdíly patří do vašich poznámek vedle štítku, protože vysvětlují chování, které jinak vypadá jako závada resolveru.

Objevování není autentizace

Odpověď SRV říká, kam se připojit, a neříká nic o tom, komu věřit, když tam dorazíte. Nechte validaci certifikátu a kontroly identity serveru na klientovi přesně tak, jak byly, protože záznam, který může někdo jiný zfalšovat, by se neměl stát rozhodnutím o důvěře. Odpovědi DNS jsou kešovatelné a upravitelné tím, kdo zónu ovládá, což z nich dělá špatné místo pro zakódování politiky.

Klientovi bez podpory objevování distribuujte profil nebo URL brány, které přijímá, a poznamenejte si, který produkt používá kterou metodu. Tato poznámka zabrání dalšímu správci přidat záznam a čekat, že bude fungovat všude. Specifikace SRV popisuje výběr mezi cíli a číst ji jako autorizační mechanismus je cesta, jak se užitečný záznam stane bezpečnostním předpokladem. Zveřejňujte vědomě, pojmenujte štítek ve své dokumentaci a ke klientovi přistupujte jako ke komponentě, která rozhoduje, zda na tom vůbec záleží.