Følg DNS-spørringen hopp for hopp for å finne den virkelige kilden
En pådyttet resolveradresse avgjør ikke hvilken kilde resolveren ser. Spor klienten, videresenderen og den mottakende serveren, og skriv ned stien.
Å gi en klient en resolveradresse avgjør hvor spørringer sendes, ikke hvilken kilde resolveren vil se. Ruting, videresending og oversettelse får hver sin runde mellom de to endene. En runbook for kildespørsmål følger spørringen hopp for hopp og noterer hva hver observatør faktisk så. Rekkefølgen betyr noe, for en påstand som fremsettes før observasjonen er bare en gjetning med bedre formatering.
Skriv ned oppsettet før du samler bevis
Fire steder kan fortelle deg noe om en DNS-kilde, og de forteller ikke alle det samme. Klientkjernen vet hvilken kilde den ville brukt, en videresender vet hva den sendte oppstrøms, en oversettende enhet vet hva den skrev om, og den mottakende resolveren vet hva som ankom. Skriv ned hvilke av disse du faktisk kan nå før du samler noe.
| 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 forventningen din, inkludert resolveren du tror er i bruk. En delt rute kan sende en spørring helt andre steder, og en hurtigbuffer kan svare uten noen oppstrømsutveksling i det hele tatt, så en antakelse som bare holdes i minnet overlever ikke den første overraskelsen. Hold det angitte designet og den observerte stien i separate kolonner i samme notat; når de to er uenige, har du funnet spørsmålet som er verdt å forfølge.
Kontroller hvilken prosess som faktisk sendte spørringen
Start hos klienten: noter resolveradressen, spørringsnavnet og tidspunktet, og bekreft deretter hvilken prosess som sendte den. Den første linjen nedenfor navngir prosessen som holder UDP-socketten, og det er kontrollen denne overskriften lover. Er den prosessen en nettleserhjelper eller en containerruntime i stedet for systemresolveren, beskriver resten av sporet en sti ingen ba om.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Finn på en vert med flere grensesnitt først ut hvilken kildeadresse kjernen velger for den destinasjonen, før du ser noe annet sted. Det er det siste punktet der stien er helt under din kontroll, og det er verdien du sammenligner med det resolveren rapporterer. Et avvik er signalet om at noe imellom skrev om pakken, eller at to forskjellige spørringer ble sendt.
Hold testnavnene interne, for et internt navn som sendes til en offentlig resolver beviser ingenting om den interne stien og publiserer et navn du ikke trengte å publisere. En nettleser med sikker DNS påslått vises ikke i den socket-listen i det hele tatt, og det fraværet er selv svaret.
Videresenderen lager en andre, separat spørring
En videresender gjør én utveksling til to. Den nedstrøms forespørselen ankommer, og videresenderen sender deretter sin egen spørring oppstrøms fra en adresse den velger. Konfigurasjonen, ikke klienten, avgjør hva oppstrømsresolveren ser.
dnsmasq-manualen er lesverdig av den grunn: den dokumenterer hvordan en videresender velger oppstrømsservere og binder sin lytteside, og ingenting i det oppsettet bærer klientkilden oppstrøms. En resolverlogg som viser en gatewayadresse er derfor normalt og ikke bevis på en feil. Fravær er like lett å lese feil, for et hurtigbuffertreff gir ingen oppstrømsspørring og ser identisk ut med en spørring som aldri ankom. Les videresenderkonfigurasjonen og hurtigbuffertilstanden før du trekker noen av de to konklusjonene. To spørsmål, to steder å se.
Les kilden ved den mottakende resolveren
Den eneste observasjonen som avgjør dette, tas på serversiden. Alt som utledes fra klientens grensesnittliste forblir en hypotese til resolveren rapporterer hva som faktisk ankom.
tcpdump -ni any port 53 and host 10.20.30.53Ta opp på resolververten, hold opptaket kort og avgrenset, og lagre det der policyen tillater det. Hvis den observerte kilden er en oversatt adresse, er neste spørsmål hvilken enhet som utførte oversettelsen og om policyen er den tiltenkte. Et opptak svarer på hva som ankom; det forklarer ikke hvorfor policyen tillot det. Navngi observatøren og hoppet i notatet, for en personvernpåstand om en gateway er en påstand om det hoppet og ikke om hele stien.
Skriv funnet som en sti, ikke en adresse
Noter klienten, resolveren, eventuell videresender, den observerte kilden ved hvert hopp og policyen som styrer det. Den registreringen svarer på de fleste fremtidige spørsmål uten et nytt opptak. Tegn den som en kjede, for en liste med adresser skjuler hvilket hopp som ga hvilken.
Fest datoen, klientversjonen og konfigurasjonsrevisjonen til tegningen, slik at en senere leser kan se om den fortsatt gjelder. Skill transportkilden fra alt annet tjenesten behandler, for å se en gatewayadresse sier ingenting om hva som ellers oppbevares. En resolverplassering sier heller ingenting om hvilken klient som spurte. Å holde disse påstandene fra hverandre er det som gjør konklusjonen forsvarlig under gjennomgang.