Miért csak annak a kliensnek segít az SRV-rekord, amelyik maga kérdezi le

Az SRV-rekord hozzáadása a zónához nem tanít meg egyetlen VPN-klienst sem arra, hogy megkeresse. A kliensnek ismernie kell a címkét, döntenie kell a lekérdezés elküldéséről, és cselekednie kell aszerint, ami visszajön, a DNS pedig az első kettőt nem tudja biztosítani. Ezért a legtöbb sikertelen SRV-terv DNS-jelmezt öltött kliensprobléma. Először olvassa el a kliens felderítési viselkedését, aztán csak azt a címkét tegye közzé, amelyet tényleg lekérdez.

Egy rekord, amelyet senki nem kérdez le, senkinek nem segít

Az SRV közzéteszi egy szolgáltatás helyét; nem hirdeti meg. Semmi nem tol egy rekordot a kliens felé, és egyetlen feloldó sem kínál olyan nevet, amelyet soha nem kértek. A keresés akkor kezdődik, amikor az alkalmazás úgy dönt, hogy elvégzi, ezért a címkének a termék dokumentációjából vagy a szoftver hálózati megfigyeléséből kell származnia. Ahol a kliensnek nincs felderítési lépése, ott egy rekord megváltoztatja a zónát, és semmi mást.

Ezért kezdhet el működni az egyik termék egy hálózaton, miközben a másikat ugyanaz a változás nem érinti. A változó a szoftver, és a DNS-kiszolgáló pontosan azt teszi, amit mondtak neki. A szerkesztés után olvassa vissza a zónát is, mert egy elgépelt címke könnyen elrejtőzik a mind egyformán kinéző rekordok között.

Olvassa el a mezőket, mielőtt beírja őket

Egy rekord négy értéket hordoz, és mindegyik más kérdésre válaszol: a prioritás rendezi azokat a célokat, amelyeket a kliens kipróbálhat, a súly elosztja a terhelést az azonos prioritású célok között, a port megnevezi a szállítási portot, a cél pedig megnevezi a gazdagépet. A specifikáció azt is megengedi, hogy egy . cél azt jelentse, hogy a szolgáltatás szándékosan nem elérhető, ami hasznos válasz, és nem törött.

Ezek egyike sem hordoz hitelesítő adatokat, tanúsítvány-szabályzatot vagy alkalmazásverziót, és a súlyt figyelmen kívül hagyó kliens is csatlakozik, csak a szándékolt egyensúly nélkül. A célnak saját címrekordokra van szüksége, és kanonikus névnek kell lennie, nem álnévnek. Egy olyan rekord közzététele, amely hallgató nélküli gazdagépre mutat, olyan kapcsolódási hibát okoz, amely DNS-hibaként olvasható, és ez a megtévesztés legdrágább fajtája. Tegye közzé a teljes láncot, vagy semmit belőle.

Keresse meg a címkét, amelyet a kliens tényleg küld

Bizonyítékok alapján állapítsa meg a címkét, ne a termék nevére vonatkozó találgatással. Vagy a dokumentáció megadja a szolgáltatás nevét, vagy egy rögzítés megmutatja a kliensből induláskor kilépő lekérdezést. Mindkét út ugyanoda vezet: pontos név és típus a feloldóval szembeni teszteléshez.

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

Hasonlítsa össze a választ a közzétett rekorddal karakterről karakterre, mert az aláhúzások és a záró pont a név része. Egy ténylegesen elküldött lekérdezésre adott üres válasz a zónára mutat, míg a lekérdezés teljes hiánya a kliensre, és ezek a megállapítások különböző csapatokhoz küldik. Egy valódi válasz úgy néz ki, mint az alábbi sor, ahol a 20 prioritás elveszít minden alacsonyabb prioritású rekorddal szemben, és a kliens a 8443 portot tárcsázza a megnevezett célon.

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

A célnak is léteznie kell

Egy feloldódó cél nem ugyanaz, mint egy válaszoló szolgáltatás. Ellenőrizze a cél címrekordjait, majd ellenőrizze, hogy valami hallgat a közzétett porton és protokollon. Egy csak UDP-hallgatóra mutató TCP-rekord olyan ellentmondás, amelyet semmilyen zónaszerkesztés nem javít meg. Tartsa rövidnek a TTL-t, amíg a cél mozgásban van, és hosszabbítsa meg, amikor a név abbahagyja a mozgást.

A felderítést tényleg megvalósító kliensek abban különböznek, mennyit tartanak tiszteletben a rekordból. Néhányan csak a prioritást használják, néhányan a súlyt tanácsadónak tekintik, és kevesen figyelmen kívül hagyják a portot, és alapértelmezést feltételeznek. Ezek a különbségek a címke melletti jegyzeteibe tartoznak, mert megmagyarázzák azt a viselkedést, amely egyébként feloldóhibának tűnik.

A felderítés nem hitelesítés

Az SRV-válasz megmondja, hová kell csatlakozni, és semmit nem mond arról, kiben bízzon az érkezés után. Hagyja a kliens tanúsítvány-ellenőrzését és kiszolgálóidentitás-ellenőrzéseit pontosan úgy, ahogy voltak, mert egy rekord, amelyet más meghamisíthat, nem válhat bizalmi döntéssé. A DNS-válaszok gyorsítótárazhatók és a zónát irányító bárki által szerkeszthetők, ami alkalmassá teszi őket arra, hogy rossz hely legyen a szabályzat kódolására.

A felderítést nem támogató kliensnek ossza ki azt a profilt vagy átjáró-URL-t, amelyet elfogad, és jegyezze fel, melyik termék melyik módszert használja. Ez a feljegyzés megakadályozza, hogy a következő rendszergazda rekordot adjon hozzá, és azt várja, hogy mindenhol működik. Az SRV-specifikáció a célok közötti választást írja le, és felhatalmazási mechanizmusként olvasni azt az út, amelyen egy hasznos rekord biztonsági feltevéssé válik. Tegye közzé szándékosan, nevezze meg a címkét a dokumentációjában, és kezelje a klienst azként az összetevőként, amely eldönti, hogy mindennek van-e jelentősége.