Spuri la DNS-demandon paŝo post paŝo por trovi la veran fonton
Peligita resolvila adreso ne decidas, kiun fonton la resolvilo vidos. Spuru la klienton, la plusendilon kaj la ricevan servilon, kaj skribu la vojon.
Doni al kliento resolvilan adreson fiksas, kien oni sendas demandojn, ne kiun fonton la resolvilo vidos. Enkursigo, plusendado kaj tradukado ĉiu ricevas sian vicon inter la du finoj. Manlibro por fontaj demandoj sekvas la demandon paŝo post paŝo kaj notas, kion ĉiu observanto vere vidis. La ordo gravas, ĉar aserto farita antaŭ la observado estas nur konjekto kun pli bona formatado.
Skribu la aranĝon antaŭ ol kolekti pruvojn
Kvar lokoj povas diri al vi ion pri DNS-fonto, kaj ne ĉiuj diras la saman. La klienta kerno scias, kiun fonton ĝi uzus, plusendilo scias, kion ĝi sendis supren, tradukanta aparato scias, kion ĝi reskribis, kaj la ricevanta resolvilo scias, kio alvenis. Skribu, kiujn el tiuj vi vere povas atingi antaŭ ol kolekti ion ajn.
| 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 |
Skribu ankaŭ vian atendo, inkluzive la resolvilon, kiun vi kredas esti uzata. Disigita vojo povas sendi demandon tute aliloken, kaj kaŝmemoro povas respondi sen iu ajn suprena interŝanĝo, do supozo tenata nur en memoro ne postvivos la unuan surprizon. Tenu la deklarita dezajno kaj la observita vojo en apartaj kolumnoj de la sama noto; kiam la du malkongruas, vi trovis la demandon indan je persekutado.
Kontrolu, kiu procezo vere sendis la demandon
Komencu ĉe la kliento: notu la resolvilan adreson, la demandan nomon kaj la tempon, poste konfirmu, kiu procezo ĝin sendis. La unua linio sube nomas la procezon, kiu tenas la UDP-ingon, kaj tio estas la kontrolo, kiun promesas ĉi tiu rubriko. Se tiu procezo estas retumila helpilo aŭ uja plenummedio anstataŭ la sistema resolvilo, la resto de la spuro priskribas vojon, kiun neniu petis.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Sur gastiganto kun pluraj interfacoj, eltrovu, kiun fontan adreson la kerno elektas por tiu celo antaŭ ol rigardi aliloken. Tio estas la lasta punkto, kie la vojo estas tute sub via kontrolo, kaj ĝi estas la valoro, kiun vi komparos kun tio, kion raportas la resolvilo. Malkongruo estas la signo, ke io intere reskribis la paketon, aŭ ke estis senditaj du malsamaj demandoj.
Tenu la testajn nomojn internaj, ĉar interna nomo sendita al publika resolvilo pruvas nenion pri la interna vojo kaj publikigas nomon, kiun vi ne bezonis publikigi. Retumilo kun sekura DNS ŝaltita tute ne aperos en tiu ingolisto, kaj tiu foresto mem estas la respondo.
La plusendilo faras duan, apartan demandon
Plusendilo transformas unu interŝanĝon en du. La malsuprena peto alvenas, kaj poste la plusendilo sendas sian propran demandon supren de adreso, kiun ĝi elektas. Ĝia agordo, ne la kliento, decidas, kion vidas la suprena resolvilo.
La manlibro de dnsmasq indas legi pro tiu kialo: ĝi dokumentas, kiel plusendilo elektas suprenajn servilojn kaj ligas sian aŭskultan flankon, kaj nenio en tiu aranĝo portas la klientan fonton supren. Resolvila protokolo montranta enirejan adreson estas do normala, ne pruvo de misfunkcio. Foresto same facile mislegeblas, ĉar kaŝmemora trafo produktas neniun suprenan demandon kaj aspektas idente al demando, kiu neniam alvenis. Legu la agordon de la plusendilo kaj ĝian kaŝmemoran staton antaŭ ol tiri iun el la du konkludoj. Du demandoj, du lokoj por rigardi.
Legu la fonton ĉe la ricevanta resolvilo
La sola observado, kiu solvas tion, estas farata ĉe la servila flanko. Ĉio, kio deduktiĝas el la interfaca listo de la kliento, restas hipotezo ĝis la resolvilo raportos, kio vere alvenis.
tcpdump -ni any port 53 and host 10.20.30.53Kaptu sur la resolvila gastiganto, tenu la kaptaĵon mallonga kaj limigita, kaj konservu ĝin, kie politiko permesas. Se la observita fonto estas tradukita adreso, la sekva demando estas, kiu aparato faris la tradukon kaj ĉu ĝia politiko estas la celita. Kaptaĵo respondas, kio alvenis; ĝi ne klarigas, kial la politiko permesis tion. Nomu la observanton kaj la paŝon en la noto, ĉar privateca aserto pri enirejo estas aserto pri tiu paŝo, ne pri la tuta vojo.
Skribu la trovaĵon kiel vojon, ne kiel adreson
Notu la klienton, la resolvilon, ajnan plusendilon, la observitan fonton ĉe ĉiu paŝo kaj la politikon, kiu regas ĝin. Tiu registro respondas al plej multaj estontaj demandoj sen plia kaptaĵo. Desegnu ĝin kiel ĉenon, ĉar adresa listo kaŝas, kiu paŝo produktis kiun.
Aldonu la daton, la klientan version kaj la agordan revizion al la desegno, por ke posta leganto povu diri, ĉu ĝi ankoraŭ validas. Apartigu la transportan fonton de ĉio alia, kion la servo prilaboras, ĉar vidi enirejan adreson diras nenion pri tio, kio alie konserviĝas. Ankaŭ la loko de resolvilo diras nenion pri tio, kiu kliento demandis. Teni tiujn asertojn aparte estas tio, kio faras la konkludon defendebla en revizio.