Följ DNS-frågan hopp för hopp för att hitta den verkliga källan
En påtvingad resolveradress avgör inte vilken källa resolvern ser. Spåra klienten, vidarebefordraren och den mottagande servern och skriv ner vägen.
Att ge en klient en resolveradress avgör vart frågor skickas, inte vilken källa resolvern kommer att se. Routing, vidarebefordran och översättning får var sin tur mellan de två ändarna. En runbook för källfrågor följer frågan hopp för hopp och antecknar vad varje observatör faktiskt såg. Ordningen spelar roll, för ett påstående som görs före observationen är bara en gissning med bättre formatering.
Skriv ner upplägget innan du samlar bevis
Fyra platser kan berätta något om en DNS-källa, och de säger inte alla samma sak. Klientkärnan vet vilken källa den skulle använda, en vidarebefordrare vet vad den skickade uppströms, en översättande enhet vet vad den skrev om, och den mottagande resolvern vet vad som anlände. Skriv ner vilka av dem du faktiskt kan nå innan du samlar något.
| 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 också ner din förväntan, inklusive den resolver du tror används. En delad rutt kan skicka en fråga någon helt annanstans, och en cache kan svara utan något uppströmsutbyte alls, så ett antagande som bara hålls i minnet överlever inte den första överraskningen. Håll den angivna designen och den observerade vägen i separata kolumner i samma anteckning; när de två inte stämmer har du hittat frågan som är värd att förfölja.
Kontrollera vilken process som faktiskt skickade frågan
Börja vid klienten: anteckna resolveradressen, frågenamnet och tiden och bekräfta sedan vilken process som skickade den. Den första raden nedan namnger processen som håller UDP-uttaget, och det är den kontroll som rubriken utlovar. Är den processen en webbläsarhjälp eller en containerruntime i stället för systemresolvern, beskriver resten av spåret en väg som ingen bad om.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Ta på en värd med flera gränssnitt först reda på vilken källadress kärnan väljer för det målet innan du tittar någon annanstans. Det är den sista punkten där vägen är helt under din kontroll, och det är det värde du jämför med vad resolvern rapporterar. En avvikelse är signalen att något däremellan skrev om paketet, eller att två olika frågor skickades.
Håll testnamnen interna, för ett internt namn som skickas till en offentlig resolver bevisar inget om den interna vägen och publicerar ett namn du inte behövde publicera. En webbläsare med säker DNS påslagen syns inte alls i den uttagslistan, och den frånvaron är själv svaret.
Vidarebefordraren gör en andra, separat fråga
En vidarebefordrare gör ett utbyte till två. Den nedströms begäran anländer, och vidarebefordraren skickar sedan sin egen fråga uppströms från en adress den väljer. Dess konfiguration, inte klienten, avgör vad uppströmsresolvern ser.
dnsmasq-manualen är läsvärd av det skälet: den dokumenterar hur en vidarebefordrare väljer uppströmsservrar och binder sin lyssningssida, och inget i det upplägget bär klientkällan uppströms. En resolverlogg som visar en gatewayadress är därför normal och inte bevis på ett fel. Frånvaro är lika lätt att läsa fel, för en cacheträff ger ingen uppströmsfråga och ser identisk ut med en fråga som aldrig anlände. Läs vidarebefordrarens konfiguration och dess cachetillstånd innan du drar någon av de två slutsatserna. Två frågor, två ställen att titta på.
Läs källan vid den mottagande resolvern
Den enda observation som avgör detta görs på serversidan. Allt som härleds från klientens gränssnittslista förblir en hypotes tills resolvern rapporterar vad som faktiskt anlände.
tcpdump -ni any port 53 and host 10.20.30.53Fånga på resolvervärden, håll fångsten kort och avgränsad och lagra den där policyn tillåter. Om den observerade källan är en översatt adress är nästa fråga vilken enhet som utförde översättningen och om dess policy är den avsedda. En fångst svarar på vad som anlände; den förklarar inte varför policyn tillät det. Namnge observatören och hoppet i anteckningen, för ett integritetspåstående om en gateway är ett påstående om det hoppet och inte om hela vägen.
Skriv fyndet som en väg, inte som en adress
Anteckna klienten, resolvern, varje vidarebefordrare, den observerade källan vid varje hopp och policyn som styr det. Den anteckningen besvarar de flesta framtida frågor utan ännu en fångst. Rita den som en kedja, för en lista med adresser döljer vilket hopp som gav vilken.
Fäst datumet, klientversionen och konfigurationsrevisionen vid ritningen, så att en senare läsare kan avgöra om den fortfarande gäller. Skilj transportkällan från allt annat tjänsten behandlar, för att se en gatewayadress säger inget om vad som annars sparas. En resolverplats säger inte heller något om vilken klient som frågade. Att hålla de påståendena åtskilda är det som gör slutsatsen hållbar vid granskning.