Split-DNS-rögzítés: mondja meg, hol készült az egyes megfigyelés

Két ember ugyanazt a Split-DNS-problémát vizsgálja, és különböző resolver-címeket kap. Az egyik keresőeszközt használt, a másik csomagokat rögzített az adapteren, a harmadik pedig a kliens saját diagnosztikáját olvasta. Egyikük sem hazudik, és egyikük sem ugyanazt a szakaszt írja le. A megfigyelési pont megnevezése ellentmondásból térképet csinál.

Egy keresés, több megfigyelési pont

Egyetlen belső névhez legalább öt hely van, ahol érdemes megnézni: az alkalmazás és az általa hívott resolver API, a kliensen érvényes doménszabály, az adapteren vagy szűrőn végzett rögzítés, egy felügyelt átjáróhatár és az a resolver, amely ténylegesen fogadja a lekérést.

Mindegyik más kérdésre válaszol, és egyik sem bizonyítja önmagában, hová ment a lekérés.

Az adapteren végzett rögzítés csomagokat mutat, nem szándékot. Nem mondja meg, melyik resolveret választotta a kliens, és az üres rögzítés gyorsítótárazott választ vagy másik resolver APIt jelenthet eldobott csomag helyett. Kezeljen minden megfigyelést egy szakaszra vonatkozó bizonyítékként. Ezután állítsa össze a szakaszokat egy útvonallá.

A kliens szűrője az alkalmazás és a vezeték között ül

A Split-DNS-t használó VPN-kliens a csomag gépről való kilépése előtt alkalmazza a doménegyeztetést. Az alagútba sorolt utótag nevei a belső resolverhez mennek; minden más a helyihez. A szűrő szabály, és a szabály platformonként és klienstől függően eltérhet.

A Cisco Secure Client Split-DNS útmutatója lefedi a doménegyeztetést és a Windows-szűrőt, és különválasztja, mit lát az alkalmazás a natív resolver API használatakor attól, mit lát egy nslookuphoz hasonló eszköz. Pont ezek a különbségek a lényeg.

Induljon ki az érvényes profilból és egy szokásos alkalmazáslekérésből. Minden teszt, amely kifejezett kiszolgálót nevez meg, szándékos kerülőút; magyarázza meg a kliens saját diagnosztikájával, és ne engedje, hogy elfogadási feltétellé váljon.

Az nslookup más úton halad, mint az alkalmazás

Az nslookup saját DNS-lekérést épít, és megkerülheti az operációs rendszer resolver-szabályát. Ez hasznos eszközzé teszi arra, hogy egy adott kiszolgálónak adott kérdést tegyen fel, és félrevezető eszközzé arra, hogy tesztelje, mit fog az alkalmazás tapasztalni.

Windows alatt a névfeloldási szabálytáblázat dönti el, melyik utótag melyik kiszolgálót használja. Elolvasása megmutatja a szabályt, amelyet az alkalmazás követni fog, és gyakran épp ez a hiányzó darab.

Olvassa el a szabályt, majd tegye fel ugyanezt a kérdést a normál resolveren keresztül:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

A titkosított resolverek a lekérést rejtik el, nem a kapcsolatot

A saját DNS-over-HTTPS resolverrel rendelkező böngésző egészen más eset. A lekérés TLS-en belül lép ki, ezért a csomagrögzítés resolver-cím felé mutató kapcsolatot mutat, de a kért nevet nem.

Először derítse ki a böngésző kezelt szabályát, majd hasonlítsa össze az operációs rendszer lekérésével. Lehet, hogy a saját resolverét választani engedett böngésző soha nem látja a Split-DNS szabályt.

Ugyanez az óvatosság vonatkozik minden kliensre, amely saját resolvert hoz. A távoli kapcsolatot azonosító rögzítés nem bizonyíték a lekérés nevére. Ha kell a név, vegye a resolver saját naplóiból vagy az alkalmazás diagnosztikájából, az alkalmazandó adatvédelmi szabályokkal.

Hasonlítsa össze egy címkézett teszttel

Válasszon egy jóváhagyott belső nevet a teszthez, valamint egy nyilvános nevet, amely nem hordoz érzékeny jelentést. Mindegyiknél jegyezze fel az időt, a rekordtípust, a választ és a várt szabályt.

Ahol megengedett, hasonlítsa össze a resolver fogadását egyetlen szűk kliens- vagy átjárómegfigyeléssel:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Soha ne küldjön privát neveket nem kapcsolódó nyilvános resolvereknek csak azért, hogy összehasonlítást hozzon létre, és szerkessze mindazt, amit megoszt. Végül különítse el a helyes DNS-választ a következő szolgáltatáskapcsolattól: a feloldott privát címnek továbbra is kell útvonal és alkalmazásengedély.