Kövesse lépésről lépésre a DNS-lekérdezést, hogy megtalálja a valódi forrást
A kikényszerített resolver-cím nem dönti el, melyik forrást látja a resolver. Kövesse a klienst, a továbbítót és a fogadó kiszolgálót, majd írja le az útvonalat.
Ha egy kliensnek resolver-címet adunk, az eldönti, hova mennek a lekérdezések, nem azt, hogy melyik forrást fogja látni a resolver. Az útválasztás, a továbbítás és a fordítás mind kap egy-egy kört a két végpont között. A forráskérdésekhez készült runbook lépésről lépésre követi a lekérdezést, és feljegyzi, mit látott valójában az egyes megfigyelő. A sorrend számít, mert a megfigyelés előtt tett állítás csak jobban formázott találgatás.
Írja le az elrendezést, mielőtt bizonyítékot gyűjt
Négy hely tud valamit mondani egy DNS-forrásról, és nem mind ugyanazt mondja. A kliens kernel tudja, melyik forrást használná, a továbbító tudja, mit küldött felfelé, a fordító eszköz tudja, mit írt át, és a fogadó resolver tudja, mi érkezett meg. Írja le, melyikeket érheti el valóban, mielőtt bármit gyűjtene.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Írja le az elvárását is, beleértve azt a resolvert, amelyről azt hiszi, hogy használatban van. Egy osztott útvonal teljesen máshova küldheti a lekérdezést, és a gyorsítótár felfelé irányuló csere nélkül is válaszolhat, ezért a csak memóriában tartott feltevés nem éli túl az első meglepetést. Tartsa a kimondott tervet és a megfigyelt útvonalat ugyanazon feljegyzés külön oszlopaiban; amikor a kettő nem egyezik, megtalálta a kérdést, amelyet érdemes üldözni.
Ellenőrizze, melyik folyamat küldte valójában a lekérdezést
Kezdje a kliensnél: jegyezze fel a resolver címét, a lekérdezés nevét és az időt, majd erősítse meg, melyik folyamat küldte. Az alábbi első sor megnevezi az UDP-csatornát tartó folyamatot, és ez az az ellenőrzés, amelyet ez a cím ígér. Ha ez a folyamat böngésző-segéd vagy konténer-futtatókörnyezet a rendszerresolver helyett, a nyom többi része olyan útvonalat ír le, amelyet senki sem kért.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Több interfésszel rendelkező hoszton először állapítsa meg, melyik forrás-címet választja a kernel ehhez a célhoz, mielőtt bárhova máshova nézne. Ez az utolsó pont, ahol az útvonal teljesen az Ön ellenőrzése alatt áll, és ez az az érték, amelyet a resolver jelentésével összevet. Az eltérés annak a jele, hogy valami közben átírta a csomagot, vagy hogy két különböző lekérdezés ment ki.
Tartsa a tesztneveket belsőnek, mert egy nyilvános resolvernek küldött belső név semmit sem bizonyít a belső útvonalról, és olyan nevet tesz közzé, amelyet nem kellett volna. A biztonságos DNS-t bekapcsoló böngésző egyáltalán nem jelenik meg abban a csatornalistában, és ez a hiány maga a válasz.
A továbbító egy második, külön lekérdezést indít
A továbbító egy cserét kettővé alakít. A lefelé irányuló kérés megérkezik, majd a továbbító a saját lekérdezését küldi felfelé egy általa választott címről. A konfigurációja, nem a kliens, dönti el, mit lát a felső resolver.
A dnsmasq kézikönyv éppen ezért érdemes olvasásra: dokumentálja, hogyan választ a továbbító felső kiszolgálókat, és hogyan köti a figyelő oldalát, és ebben az elrendezésben semmi nem viszi felfelé a kliens forrását. Az átjáró-címet mutató resolver-napló ezért normális, és nem hiba bizonyítéka. A hiányt ugyanilyen könnyű félreolvasni, mert a gyorsítótári találat nem hoz létre felfelé irányuló lekérdezést, és pontosan úgy néz ki, mint egy soha meg nem érkezett lekérdezés. Olvassa el a továbbító konfigurációját és gyorsítótárának állapotát, mielőtt bármelyik következtetést levonja. Két kérdés, két hely, ahol érdemes megnézni.
Olvassa le a forrást a fogadó resolveren
Az egyetlen megfigyelés, amely ezt eldönti, a kiszolgáló oldalán történik. Minden, amit a kliens interfészlistájából kikövetkeztetünk, hipotézis marad, amíg a resolver nem jelenti, mi érkezett meg valójában.
tcpdump -ni any port 53 and host 10.20.30.53Rögzítsen a resolver hosztján, tartsa a rögzítést rövidre és körülhatároltra, és tárolja ott, ahol a szabályzat engedi. Ha a megfigyelt forrás fordított cím, a következő kérdés az, melyik eszköz végezte a fordítást, és hogy a szabályzata a szándékolt-e. A rögzítés megválaszolja, mi érkezett meg; nem magyarázza meg, miért engedte meg a szabályzat. Nevezze meg a megfigyelőt és a lépést a feljegyzésben, mert az átjáróra vonatkozó adatvédelmi állítás arról a lépésről szól, nem a teljes útvonalról.
Írja le a megállapítást útvonalként, ne címként
Jegyezze fel a klienst, a resolvert, minden továbbítót, az egyes lépéseknél megfigyelt forrást és az azt szabályozó szabályzatot. Ez a feljegyzés a legtöbb jövőbeli kérdésre válaszol újabb rögzítés nélkül. Rajzolja láncként, mert a címek listája elrejti, melyik lépés melyiket adta.
Csatolja a rajzhoz a dátumot, a kliens verzióját és a konfiguráció revízióját, hogy egy későbbi olvasó meg tudja mondani, érvényes-e még. Válassza külön a szállítási forrást mindentől, amit a szolgáltatás feldolgoz, mert az átjáró-cím látványa semmit sem mond arról, mi mást őriznek meg. A resolver helye sem mond semmit arról, melyik kliens kérdezett. Ezen állítások szétválasztása az, ami a következtetést felülvizsgálat esetén védhetővé teszi.