Sledujte dopyt DNS krok za krokom, aby ste našli skutočný zdroj
Vnútená adresa resolvera nerozhoduje o tom, aký zdroj resolver uvidí. Sledujte klienta, forwarder a prijímajúci server a zapíšte cestu.
Odovzdať klientovi adresu resolvera určuje, kam sa dopyty posielajú, nie aký zdroj resolver uvidí. Smerovanie, preposielanie a preklad dostávajú medzi oboma koncami svoj diel. Runbook pre otázky zdroja sleduje dopyt krok za krokom a zaznamenáva, čo každý pozorovateľ skutočne videl. Na poradí záleží, pretože tvrdenie vyslovené pred pozorovaním je len domnienka v lepšom formáte.
Zapíšte usporiadanie, skôr než začnete zbierať dôkazy
Štyri miesta vám môžu o zdroji DNS niečo povedať a nie všetky hovoria to isté. Jadro klienta vie, aký zdroj by použilo, forwarder vie, čo odoslal nahor, prekladajúce zariadenie vie, čo prepísalo, a prijímajúci resolver vie, čo dorazilo. Zapíšte, na ktoré z nich skutočne dosiahnete, skôr než čokoľvek zozbierate.
| 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 |
Zapíšte aj svoje očakávanie, vrátane resolvera, o ktorom si myslíte, že je v prevádzke. Rozdelená trasa môže poslať dopyt úplne inam a medzipamäť môže odpovedať bez akejkoľvek výmeny nahor, takže predpoklad držaný len v pamäti prvé prekvapenie neprežije. Držte deklarovaný návrh a pozorovanú cestu v oddelených stĺpcoch tej istej poznámky; keď sa obe rozchádzajú, našli ste otázku, ktorá stojí za sledovanie.
Skontrolujte, ktorý proces dopyt skutočne odoslal
Začnite pri klientovi: zapíšte adresu resolvera, názov dopytu a čas a potom potvrďte, ktorý proces ho odoslal. Prvý riadok nižšie pomenúva proces, ktorý drží socket UDP, a to je kontrola, ktorú tento nadpis sľubuje. Ak je tým procesom pomocník prehliadača alebo runtime kontajnera namiesto systémového resolvera, zvyšok stopy opisuje cestu, o ktorú nikto nežiadal.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Na hostiteľovi s viacerými rozhraniami najprv zistite, ktorú zdrojovú adresu jadro pre tento cieľ zvolí, skôr než sa pozriete inam. To je posledný bod, kde je cesta plne pod vašou kontrolou, a je to hodnota, ktorú porovnáte s tým, čo hlási resolver. Nezhoda je signál, že niečo medzi tým prepísalo paket, alebo že boli odoslané dva rôzne dopyty.
Držte testovacie názvy interné, pretože interný názov odoslaný verejnému resolveru nič nedokazuje o internej ceste a zverejňuje názov, ktorý ste zverejňovať nemuseli. Prehliadač so zapnutým zabezpečeným DNS sa v tom zozname socketov vôbec neobjaví a tá neprítomnosť je sama odpoveďou.
Forwarder vytvára druhý, samostatný dopyt
Forwarder mení jednu výmenu na dve. Požiadavka zdola dorazí a forwarder potom odošle svoj vlastný dopyt nahor z adresy, ktorú si zvolí. Jeho konfigurácia, nie klient, rozhoduje o tom, čo horný resolver uvidí.
Manuál dnsmasq stojí za prečítanie práve preto: dokumentuje, ako forwarder vyberá servery nahor a viaže svoju počúvaciu stranu, a nič v tomto usporiadaní nenesie zdroj klienta nahor. Log resolvera zobrazujúci adresu brány je preto normálny a nie dôkaz poruchy. Neprítomnosť sa dá rovnako ľahko prečítať nesprávne, pretože zásah v medzipamäti nevytvára žiadny dopyt nahor a vyzerá rovnako ako dopyt, ktorý nikdy nedorazil. Prečítajte si konfiguráciu forwardera a stav jeho medzipamäti, skôr než vyvodíte ktorýkoľvek z tých dvoch záverov. Dve otázky, dve miesta, kam sa pozrieť.
Prečítajte zdroj na prijímajúcom resolveri
Jediné pozorovanie, ktoré to rozrieši, sa robí na strane servera. Všetko odvodené zo zoznamu rozhraní klienta zostáva hypotézou, kým resolver neoznámi, čo skutočne dorazilo.
tcpdump -ni any port 53 and host 10.20.30.53Zachyťte na hostiteľovi resolvera, udržte záznam krátky a ohraničený a uložte ho tam, kde to politika dovoľuje. Ak je pozorovaným zdrojom preložená adresa, ďalšou otázkou je, ktoré zariadenie preklad vykonalo a či je jeho politika tá zamýšľaná. Záznam odpovedá na to, čo dorazilo; nevysvetľuje, prečo to politika povolila. Pomenujte pozorovateľa a krok v poznámke, pretože tvrdenie o súkromí týkajúce sa brány je tvrdenie o tomto kroku, nie o celej ceste.
Zapíšte zistenie ako cestu, nie ako adresu
Zapíšte klienta, resolver, prípadný forwarder, pozorovaný zdroj v každom kroku a politiku, ktorá ho riadi. Taký záznam odpovedá na väčšinu budúcich otázok bez ďalšieho záznamu. Nakreslite ho ako reťaz, pretože zoznam adries skrýva, ktorý krok dal ktorú.
Pripojte k nákresu dátum, verziu klienta a revíziu konfigurácie, aby neskorší čitateľ mohol povedať, či stále platí. Oddeľte transportný zdroj od všetkého ostatného, čo služba spracúva, pretože pohľad na adresu brány nič nehovorí o tom, čo ďalšie sa uchováva. Ani umiestnenie resolvera nič nehovorí o tom, ktorý klient sa pýtal. Práve oddržanie týchto tvrdení robí záver obhájiteľným pri revízii.