Sledujte dotaz DNS krok za krokem, abyste našli skutečný zdroj
Vnucená adresa resolveru nerozhoduje o tom, jaký zdroj resolver uvidí. Sledujte klienta, forwarder a přijímající server a zapište cestu.
Předat klientovi adresu resolveru určuje, kam se dotazy posílají, ne jaký zdroj resolver uvidí. Směrování, přeposílání a překlad dostávají mezi oběma konci svůj díl. Runbook pro otázky zdroje sleduje dotaz krok za krokem a zaznamenává, co každý pozorovatel skutečně viděl. Na pořadí záleží, protože tvrzení vyslovené před pozorováním je jen domněnka v lepším formátu.
Zapište uspořádání, než začnete sbírat důkazy
Čtyři místa vám mohou o zdroji DNS něco říct a ne všechna říkají totéž. Jádro klienta ví, jaký zdroj by použilo, forwarder ví, co odeslal nahoru, překládající zařízení ví, co přepsalo, a přijímající resolver ví, co dorazilo. Zapište, na která z nich skutečně dosáhnete, než cokoli sesbíráte.
| 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 |
Zapište i své očekávání, včetně resolveru, o kterém si myslíte, že je v provozu. Rozdělená trasa může poslat dotaz úplně jinam a mezipaměť může odpovědět bez jakékoli výměny nahoru, takže předpoklad držený jen v paměti první překvapení nepřežije. Držte deklarovaný návrh a pozorovanou cestu v oddělených sloupcích stejné poznámky; když se oba rozcházejí, našli jste otázku, která stojí za sledování.
Zkontrolujte, který proces dotaz skutečně odeslal
Začněte u klienta: zapište adresu resolveru, název dotazu a čas a poté potvrďte, který proces jej odeslal. První řádek níže pojmenovává proces, který drží socket UDP, a to je kontrola, kterou tento nadpis slibuje. Je-li tím procesem pomocník prohlížeče nebo runtime kontejneru místo systémového resolveru, zbytek stopy popisuje cestu, o kterou nikdo nežádal.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Na hostiteli s několika rozhraními nejprve zjistěte, kterou zdrojovou adresu jádro pro tento cíl zvolí, než se podíváte jinam. To je poslední bod, kde je cesta plně pod vaší kontrolou, a je to hodnota, kterou porovnáte s tím, co hlásí resolver. Neshoda je signál, že něco mezi tím přepsalo paket, nebo že byly odeslány dva různé dotazy.
Držte testovací názvy interní, protože interní název odeslaný veřejnému resolveru nic nedokazuje o interní cestě a zveřejňuje název, který jste zveřejňovat nemuseli. Prohlížeč se zapnutým zabezpečeným DNS se v tom seznamu socketů vůbec neobjeví a ta nepřítomnost je sama odpovědí.
Forwarder vytváří druhý, samostatný dotaz
Forwarder mění jednu výměnu ve dvě. Požadavek zespodu dorazí a forwarder pak odešle svůj vlastní dotaz nahoru z adresy, kterou si zvolí. Jeho konfigurace, ne klient, rozhoduje o tom, co horní resolver uvidí.
Manuál dnsmasq stojí za přečtení právě proto: dokumentuje, jak forwarder vybírá servery nahoru a váže svou naslouchací stranu, a nic v tomto uspořádání nenese zdroj klienta nahoru. Log resolveru zobrazující adresu brány je proto normální a není důkazem závady. Nepřítomnost se dá stejně snadno přečíst špatně, protože zásah v mezipaměti nevytváří žádný dotaz nahoru a vypadá stejně jako dotaz, který nikdy nedorazil. Přečtěte si konfiguraci forwarderu a stav jeho mezipaměti, než vyvodíte kterýkoli z těch dvou závěrů. Dvě otázky, dvě místa, kam se podívat.
Přečtěte zdroj na přijímajícím resolveru
Jediné pozorování, které to rozřeší, se pořizuje na straně serveru. Vše odvozené ze seznamu rozhraní klienta zůstává hypotézou, dokud resolver neoznámí, co skutečně dorazilo.
tcpdump -ni any port 53 and host 10.20.30.53Zachyťte na hostiteli resolveru, udržte záznam krátký a ohraničený a uložte jej tam, kde to politika dovoluje. Je-li pozorovaným zdrojem přeložená adresa, další otázkou je, které zařízení překlad provedlo a zda je jeho politika ta zamýšlená. Záznam odpovídá na to, co dorazilo; nevysvětluje, proč to politika povolila. Pojmenujte pozorovatele a krok v poznámce, protože tvrzení o soukromí týkající se brány je tvrzení o tomto kroku, ne o celé cestě.
Zapište zjištění jako cestu, ne jako adresu
Zapište klienta, resolver, případný forwarder, pozorovaný zdroj v každém kroku a politiku, která jej řídí. Takový záznam odpovídá na většinu budoucích otázek bez dalšího záznamu. Nakreslete jej jako řetěz, protože seznam adres skrývá, který krok dal kterou.
Připojte k nákresu datum, verzi klienta a revizi konfigurace, aby pozdější čtenář mohl říci, zda stále platí. Oddělte transportní zdroj od všeho ostatního, co služba zpracovává, protože pohled na adresu brány nic neříká o tom, co dalšího se uchovává. Ani umístění resolveru nic neříká o tom, který klient se ptal. Právě oddržení těchto tvrzení činí závěr obhajitelným při revizi.