Følg DNS-forespørgslen hop for hop for at finde den rigtige kilde
En påduttet resolveradresse afgør ikke, hvilken kilde resolveren ser. Følg klienten, forwarderen og den modtagende server, og skriv stien ned.
At give en klient en resolveradresse fastlægger, hvor forespørgsler sendes hen, ikke hvilken kilde resolveren vil se. Routing, videresendelse og oversættelse får hver deres tur mellem de to ender. En runbook til kildespørgsmål følger forespørgslen hop for hop og noterer, hvad hver iagttager faktisk så. Rækkefølgen betyder noget, for en påstand fremsat før iagttagelsen er bare et gæt med bedre formatering.
Skriv arrangementet ned, før du indsamler beviser
Fire steder kan fortælle dig noget om en DNS-kilde, og de fortæller ikke alle det samme. Klientkernen ved, hvilken kilde den ville bruge, en forwarder ved, hvad den sendte opstrøms, en oversættende enhed ved, hvad den skrev om, og den modtagende resolver ved, hvad der ankom. Skriv ned, hvilke af dem du faktisk kan nå, før du indsamler noget.
| 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å din forventning ned, inklusive den resolver, du tror er i brug. En splitrute kan sende en forespørgsel et helt andet sted hen, og en cache kan svare uden nogen opstrømsudveksling, så en antagelse, der kun holdes i hukommelsen, overlever ikke den første overraskelse. Hold det angivne design og den iagttagne sti i separate kolonner i samme note; når de to er uenige, har du fundet det spørgsmål, der er værd at forfølge.
Kontroller, hvilken proces der faktisk sendte forespørgslen
Begynd ved klienten: noter resolveradressen, forespørgselsnavnet og tidspunktet, og bekræft derefter, hvilken proces der sendte den. Den første linje nedenfor navngiver den proces, der holder UDP-socketten, og det er den kontrol, denne overskrift lover. Er den proces en browserhjælper eller en containerruntime i stedet for systemresolveren, beskriver resten af sporet en sti, som ingen har bedt om.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Find på en vært med flere grænseflader først ud af, hvilken kildeadresse kernen vælger til den destination, før du kigger andre steder. Det er det sidste punkt, hvor stien er helt under din kontrol, og det er den værdi, du sammenligner med, hvad resolveren rapporterer. En afvigelse er signalet om, at noget ind imellem skrev pakken om, eller at der blev sendt to forskellige forespørgsler.
Hold testnavnene interne, for et internt navn, der sendes til en offentlig resolver, beviser intet om den interne sti og offentliggør et navn, du ikke behøvede at offentliggøre. En browser med sikker DNS slået til optræder slet ikke i den socketliste, og den fraværenhed er selv svaret.
Forwarderen laver en anden, separat forespørgsel
En forwarder gør én udveksling til to. Den nedstrøms anmodning ankommer, og forwarderen sender derefter sin egen forespørgsel opstrøms fra en adresse, den vælger. Dens konfiguration, ikke klienten, afgør, hvad opstrømsresolveren ser.
dnsmasq-manualen er læsningen værd af den grund: den dokumenterer, hvordan en forwarder vælger opstrømsservere og binder sin lytteside, og intet i det arrangement bærer klientkilden opstrøms. En resolverlog, der viser en gatewayadresse, er derfor normal og ikke bevis på en fejl. Fravær er lige så let at læse forkert, for et cachehit giver ingen opstrømsforespørgsel og ser identisk ud med en forespørgsel, der aldrig ankom. Læs forwarderens konfiguration og dens cachetilstand, før du drager en af de to konklusioner. To spørgsmål, to steder at kigge.
Læs kilden ved den modtagende resolver
Den eneste iagttagelse, der afgør dette, foretages på serversiden. Alt, hvad der udledes af klientens grænsefladeliste, forbliver en hypotese, indtil resolveren rapporterer, hvad der faktisk ankom.
tcpdump -ni any port 53 and host 10.20.30.53Optag på resolverværten, hold optagelsen kort og afgrænset, og opbevar den, hvor politikken tillader det. Hvis den iagttagne kilde er en oversat adresse, er det næste spørgsmål, hvilken enhed der udførte oversættelsen, og om dens politik er den tilsigtede. En optagelse besvarer, hvad der ankom; den forklarer ikke, hvorfor politikken tillod det. Navngiv iagttageren og hoppet i noten, for en privatlivspåstand om en gateway er en påstand om det hop og ikke om hele stien.
Skriv fundet som en sti, ikke som en adresse
Noter klienten, resolveren, enhver forwarder, den iagttagne kilde ved hvert hop og den politik, der styrer det. Den registrering besvarer de fleste fremtidige spørgsmål uden endnu en optagelse. Tegn den som en kæde, for en liste af adresser skjuler, hvilket hop der gav hvilken.
Vedhæft datoen, klientversionen og konfigurationsrevisionen til tegningen, så en senere læser kan se, om den stadig gælder. Adskil transportkilden fra alt andet, tjenesten behandler, for at se en gatewayadresse siger intet om, hvad der ellers opbevares. En resolverplacering siger heller intet om, hvilken klient der spurgte. At holde disse påstande adskilt er det, der gør konklusionen holdbar under revision.