Følg DNS-spørjinga hopp for hopp for å finne den verkelege kjelda
Ei pådytta resolveradresse avgjer ikkje kva kjelde resolveren ser. Spor klienten, videresendaren og den mottakande serveren, og skriv ned stien.
Å gje ein klient ei resolveradresse avgjer kvar spørjingar blir sende, ikkje kva kjelde resolveren vil sjå. Ruting, videresending og omsetjing får kvar sin runde mellom dei to endane. Ein runbook for kjeldespørsmål følgjer spørjinga hopp for hopp og noterer kva kvar observatør faktisk såg. Rekkefølgja betyr noko, for ein påstand som blir sett fram før observasjonen er berre ei gjetting med betre formatering.
Skriv ned oppsettet før du samlar bevis
Fire stader kan fortelje deg noko om ei DNS-kjelde, og dei fortel ikkje alle det same. Klientkjernen veit kva kjelde han ville bruke, ein videresendar veit kva han sende oppstraums, eit omsetjande system veit kva det skreiv om, og den mottakande resolveren veit kva som kom inn. Skriv ned kva av desse du faktisk kan nå før du samlar noko.
| 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 |
Skriv også ned forventninga di, inkludert resolveren du trur er i bruk. Ei delt rute kan sende ei spørjing heilt andre stader, og ein hurtigbuffer kan svare utan noka oppstraumsutveksling i det heile, så ein føresetnad som berre blir halden i minnet overlever ikkje den første overraskinga. Hald det angjevne designet og den observerte stien i separate kolonnar i same notat; når dei to er usamde, har du funne spørsmålet som er verdt å forfølgje.
Kontroller kva prosess som faktisk sende spørjinga
Start hos klienten: noter resolveradressa, spørringsnamnet og tidspunktet, og stadfest deretter kva prosess som sende ho. Den første linja nedanfor namngjev prosessen som held UDP-socketten, og det er kontrollen denne overskrifta lovar. Er den prosessen ein nettlesarhjelpar eller ein containerruntime i staden for systemresolveren, skildrar resten av sporet ein sti ingen bad om.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Finn på ein vert med fleire grensesnitt først ut kva kjeldadresse kjernen vel for den destinasjonen, før du ser nokon annan stad. Det er det siste punktet der stien er heilt under din kontroll, og det er verdien du samanliknar med det resolveren rapporterer. Eit avvik er signalet om at noko imellom skreiv om pakken, eller at to ulike spørjingar vart sende.
Hald testnamna interne, for eit internt namn som blir sendt til ein offentleg resolver beviser ingenting om den interne stien og publiserer eit namn du ikkje trong å publisere. Ein nettlesar med sikker DNS påslått viser seg ikkje i den socket-lista i det heile, og det fråværet er sjølv svaret.
Videresendaren lagar ei andre, separat spørjing
Ein videresendar gjer éin utveksling til to. Den nedstraums førespurnaden kjem inn, og videresendaren sender deretter si eiga spørjing oppstraums frå ei adresse han vel. Konfigurasjonen, ikkje klienten, avgjer kva oppstraumsresolveren ser.
dnsmasq-manualen er lesverdig av den grunn: han dokumenterer korleis ein videresendar vel oppstraumsserverar og bind si lytteside, og ingenting i det oppsettet ber klientkjelda oppstraums. Ein resolverlogg som viser ei gatewayadresse er derfor normal og ikkje bevis på ein feil. Fråvær er like lett å lese feil, for eit hurtigbuffertreff gir inga oppstraumsspørjing og ser identisk ut med ei spørjing som aldri kom inn. Les videresendarkonfigurasjonen og hurtigbuffertilstanden før du dreg nokon av dei to konklusjonane. To spørsmål, to stader å sjå.
Les kjelda ved den mottakande resolveren
Den einaste observasjonen som avgjer dette, blir gjord på serversida. Alt som blir utleidd frå grensesnittlista til klienten blir verande ein hypotese til resolveren rapporterer kva som faktisk kom inn.
tcpdump -ni any port 53 and host 10.20.30.53Tak opp på resolververten, hald opptaket kort og avgrensa, og lagre det der policyen tillèt det. Viss den observerte kjelda er ei omsett adresse, er neste spørsmål kva eining som gjorde omsetjinga og om policyen hennar er den tiltenkte. Eit opptak svarar på kva som kom inn; det forklarer ikkje kvifor policyen tillét det. Namngje observatøren og hoppet i notatet, for ein personvernpåstand om ein gateway er ein påstand om det hoppet og ikkje om heile stien.
Skriv funnet som ein sti, ikkje ei adresse
Noter klienten, resolveren, eventuell videresendar, den observerte kjelda ved kvart hopp og policyen som styrer det. Den registreringa svarar på dei fleste framtidige spørsmål utan eit nytt opptak. Teikn henne som ei kjede, for ei liste med adresser skjuler kva hopp som gav kva.
Fest datoen, klientversjonen og konfigurasjonsrevisjonen til teikninga, slik at ein seinare lesar kan sjå om ho framleis gjeld. Skil transportkjelda frå alt anna tenesta handsamar, for å sjå ei gatewayadresse seier ingenting om kva som elles blir oppbevart. Ein resolverplassering seier heller ingenting om kva klient som spurde. Å halde desse påstandane frå kvarandre er det som gjer konklusjonen forsvarleg under gjennomgang.