Sekojiet DNS vaicājumam soli pa solim, lai atrastu īsto avotu
Uzspiests resolvera adreses neizlemj, kādu avotu resolveris redz. Izsekojiet klientu, pāradresētāju un saņēmējserveri, tad pierakstiet ceļu.
Ja klientam piešķir resolvera adresi, tas nosaka, kurp tiek sūtīti vaicājumi, nevis to, kādu avotu resolveris redzēs. Maršrutēšana, pāradresēšana un tulkošana katra saņem savu kārtu starp abiem galiem. Avota jautājumu rokasgrāmata seko vaicājumam soli pa solim un pieraksta, ko katrs novērotājs patiešām redzēja. Secība ir svarīga, jo apgalvojums, kas izteikts pirms novērojuma, ir tikai minējums labākā formātā.
Pierakstiet izkārtojumu, pirms vācat pierādījumus
Četras vietas var pastāstīt kaut ko par DNS avotu, un ne visas saka vienu un to pašu. Klienta kodols zina, kādu avotu tas izmantotu, pāradresētājs zina, ko nosūtīja uz augšu, tulkojošā ierīce zina, ko pārrakstīja, un saņēmējresolveris zina, kas ieradās. Pierakstiet, kuras no tām jūs patiešām varat sasniegt, pirms kaut ko vācat.
| 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 |
Pierakstiet arī savu gaidu, tostarp resolveri, kas, jūsuprāt, tiek izmantots. Sadalīts maršruts var nosūtīt vaicājumu pavisam citur, un kešatmiņa var atbildēt bez jebkādas apmaiņas uz augšu, tāpēc pieņēmums, kas turēts tikai atmiņā, neizturēs pirmo pārsteigumu. Turiet deklarēto projektu un novēroto ceļu atsevišķās tās pašas piezīmes kolonnās; kad abi nesakrīt, jūs esat atraduši jautājumu, kuru ir vērts izsekot.
Pārbaudiet, kurš process vaicājumu patiešām nosūtīja
Sāciet pie klienta: pierakstiet resolvera adresi, vaicājuma nosaukumu un laiku, pēc tam apstipriniet, kurš process to nosūtīja. Pirmā rinda zemāk nosauc procesu, kas tur UDP ligzdu, un tā ir pārbaude, ko sola šis virsraksts. Ja šis process ir pārlūka palīgs vai konteinera izpildes vide, nevis sistēmas resolveris, pārējā pēdas daļa apraksta ceļu, kuru neviens nav lūdzis.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Resursdatorā ar vairākām saskarnēm vispirms noskaidrojiet, kuru avota adresi kodols izvēlas šim galamērķim, pirms skatāties kur citur. Tas ir pēdējais punkts, kur ceļš ir pilnībā jūsu kontrolē, un tā ir vērtība, ko salīdzināsiet ar to, ko ziņo resolveris. Neatbilstība ir signāls, ka kaut kas pa vidu pārrakstīja paketi vai tika nosūtīti divi dažādi vaicājumi.
Turiet testa nosaukumus iekšējus, jo iekšējs nosaukums, kas nosūtīts publiskam resolverim, neko nepierāda par iekšējo ceļu un publicē nosaukumu, kuru jums nevajadzēja publicēt. Pārlūks ar iespējotu drošo DNS šajā ligzdu sarakstā nemaz neparādīsies, un šī prombūtne pati ir atbilde.
Pāradresētājs veic otru, atsevišķu vaicājumu
Pāradresētājs vienu apmaiņu pārvērš divās. Pieprasījums no apakšas pienāk, un tad pāradresētājs sūta savu vaicājumu uz augšu no tā izvēlētas adreses. Viņa konfigurācija, nevis klients, nosaka, ko redz augšējais resolveris.
dnsmasq rokasgrāmata ir lasāma tieši šī iemesla dēļ: tā dokumentē, kā pāradresētājs izvēlas augšējos serverus un piesaista savu klausīšanās pusi, un nekas šajā izkārtojumā nenes klienta avotu uz augšu. Tāpēc resolvera žurnāls, kas rāda vārtejas adresi, ir normāls, nevis bojājuma pierādījums. Prombūtni tikpat viegli var nolasīt nepareizi, jo kešatmiņas trāpījums nerada nekādu vaicājumu uz augšu un izskatās tieši tāpat kā vaicājums, kas nekad nav pienācis. Izlasiet pāradresētāja konfigurāciju un tā kešatmiņas stāvokli, pirms izdarāt kādu no diviem secinājumiem. Divi jautājumi, divas vietas, kur skatīties.
Izlasiet avotu saņēmējresolverī
Vienīgais novērojums, kas to izšķir, tiek veikts servera pusē. Viss, kas izsecināts no klienta saskarņu saraksta, paliek hipotēze, līdz resolveris ziņo, kas patiešām ieradās.
tcpdump -ni any port 53 and host 10.20.30.53Uzņemiet resolvera resursdatorā, turiet uzņemšanu īsu un ierobežotu, un glabājiet to tur, kur politika atļauj. Ja novērotais avots ir tulkota adrese, nākamais jautājums ir, kura ierīce veica tulkojumu un vai tās politika ir paredzētā. Uzņemšana atbild, kas ieradās; tā neizskaidro, kāpēc politika to atļāva. Nosauciet novērotāju un soli piezīmē, jo privātuma apgalvojums par vārteju attiecas uz šo soli, nevis uz visu ceļu.
Pierakstiet atradumu kā ceļu, nevis kā adresi
Pierakstiet klientu, resolveri, jebkuru pāradresētāju, novēroto avotu katrā solī un politiku, kas to pārvalda. Šāds ieraksts atbild uz lielāko daļu nākotnes jautājumu bez jaunas uzņemšanas. Uzzīmējiet to kā ķēdi, jo adrešu saraksts slēpj, kurš solis deva kuru.
Pievienojiet zīmējumam datumu, klienta versiju un konfigurācijas revīziju, lai vēlāks lasītājs varētu pateikt, vai tā joprojām ir spēkā. Atdaliet transporta avotu no visa cita, ko apstrādā pakalpojums, jo vārtejas adreses redzēšana neko nepasaka par to, kas vēl tiek glabāts. Arī resolvera atrašanās vieta neko nepasaka par to, kurš klients jautāja. Tieši šo apgalvojumu atdalīšana padara secinājumu aizstāvamu pārbaudē.