Seuraa DNS-kyselyä askel askeleelta ja löydä todellinen lähde
Työnnetty resolver-osoite ei ratkaise, minkä lähteen resolver näkee. Seuraa asiakasta, välittäjää ja vastaanottavaa palvelinta ja kirjaa polku ylös.
Kun asiakkaalle annetaan resolver-osoite, se määrää, minne kyselyt lähtevät, ei sitä, minkä lähteen resolver näkee. Reititys, välitys ja käännös saavat kukin vuoronsa kahden pään välissä. Lähteitä koskevien kysymysten käsikirja seuraa kyselyä askel askeleelta ja kirjaa, mitä kukin havainnoija todella näki. Järjestyksellä on väliä, sillä ennen havaintoa esitetty väite on vain paremmin muotoiltu arvaus.
Kirjaa järjestely ylös ennen todisteiden keräämistä
Neliä paikkaa voi kertoa jotain DNS-lähteestä, eivätkä kaikki kerro samaa. Asiakkaan ydin tietää, mitä lähdettä se käyttäisi, välittäjä tietää, mitä se lähetti ylöspäin, kääntävä laite tietää, mitä se kirjoitti uudelleen, ja vastaanottava resolver tietää, mitä saapui. Kirjaa, mitkä niistä todella tavoitat, ennen kuin keräät mitään.
| 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 |
Kirjaa myös odotuksesi, mukaan lukien resolver, jonka uskot olevan käytössä. Jaettu reitti voi lähettää kyselyn aivan muualle, ja välimuisti voi vastata ilman mitään ylöspäin suuntautuvaa vaihtoa, joten vain muistissa pidetty oletus ei selviä ensimmäisestä yllätyksestä. Pidä ilmoitettu suunnittelu ja havaittu polku saman muistiinpanon eri sarakkeissa; kun ne kaksi ovat eri mieltä, olet löytänyt kysymyksen, jota kannattaa seurata.
Tarkista, mikä prosessi kyselyn todella lähetti
Aloita asiakkaasta: kirjaa resolver-osoite, kyselyn nimi ja aika ja vahvista sitten, mikä prosessi sen lähetti. Ensimmäinen rivi alla nimeää prosessin, jolla on UDP-socket, ja se on tarkistus, jonka tämä otsikko lupaa. Jos tuo prosessi on selaimen apuohjelma tai kontin suoritusympäristö järjestelmän resolverin sijaan, jäljen loppuosa kuvaa polkua, jota kukaan ei pyytänyt.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Monen liitännän koneella selvitä ensin, minkä lähdeosoitteen ydin valitsee kyseiselle kohteelle, ennen kuin katsot muualle. Se on viimeinen kohta, jossa polku on täysin hallinnassasi, ja se on arvo, jota vertaat resolverin raportoimaan. Poikkeama on merkki siitä, että jokin välissä kirjoitti paketin uudelleen tai että lähetettiin kaksi eri kyselyä.
Pidä testinimet sisäisinä, sillä julkiselle resolverille lähetetty sisäinen nimi ei todista sisäisestä polusta mitään ja julkaisee nimen, jota sinun ei tarvinnut julkaista. Selain, jossa suojattu DNS on päällä, ei näy tuossa socket-luettelossa lainkaan, ja se puuttuminen on itsessään vastaus.
Välittäjä tekee toisen, erillisen kyselyn
Välittäjä muuttaa yhden vaihdon kahdeksi. Alhaalta tuleva pyyntö saapuu, ja sitten välittäjä lähettää oman kyselynsä ylöspäin valitsemastaan osoitteesta. Sen konfiguraatio, ei asiakas, ratkaisee, mitä ylempi resolver näkee.
dnsmasq-käsikirja kannattaa lukea juuri tästä syystä: se dokumentoi, miten välittäjä valitsee ylemmät palvelimet ja sitoo kuuntelupuolensa, eikä mikään siinä järjestelyssä kanna asiakkaan lähdettä ylöspäin. Siksi yhdyskäytävän osoitteen näyttävä resolver-loki on normaali, ei todiste viasta. Puuttumisen voi yhtä helposti lukea väärin, sillä välimuistiosuma ei tuota mitään ylöspäin suuntautuvaa kyselyä ja näyttää täsmälleen samalta kuin kysely, joka ei koskaan saapunut. Lue välittäjän konfiguraatio ja sen välimuistin tila ennen kuin teet kummankaan johtopäätöksen. Kaksi kysymystä, kaksi paikkaa katsoa.
Lue lähde vastaanottavasta resolverista
Ainoa havainto, joka ratkaisee tämän, tehdään palvelimen puolella. Kaikki asiakkaan liitäntäluettelosta päätelty jää hypoteesiksi, kunnes resolver raportoi, mitä todella saapui.
tcpdump -ni any port 53 and host 10.20.30.53Kaappaa resolverin koneella, pidä kaappaus lyhyenä ja rajattuna ja tallenna se sinne, missä käytäntö sallii. Jos havaittu lähde on käännetty osoite, seuraava kysymys on, mikä laite teki käännöksen ja onko sen käytäntö aiottu. Kaappaus vastaa, mitä saapui; se ei selitä, miksi käytäntö salli sen. Nimeä havainnoija ja askel muistiinpanossa, sillä yhdyskäytävää koskeva yksityisyysväite koskee sitä askelta, ei koko polkua.
Kirjaa havainto polkuna, ei osoitteena
Kirjaa asiakas, resolver, mahdollinen välittäjä, havaittu lähde kullakin askeleella ja sitä ohjaava käytäntö. Sellainen kirjaus vastaa useimpiin tuleviin kysymyksiin ilman uutta kaappausta. Piirrä se ketjuna, sillä osoiteluettelo kätkee, mikä askel antoi minkä.
Liitä piirrokseen päivämäärä, asiakasversio ja konfiguraation revisio, jotta myöhempi lukija voi sanoa, onko se yhä voimassa. Erota kuljetuslähde kaikesta muusta, mitä palvelu käsittelee, sillä yhdyskäytävän osoitteen näkeminen ei kerro mitään siitä, mitä muuta säilytetään. Myöskään resolverin sijainti ei kerro mitään siitä, mikä asiakas kysyi. Juuri näiden väitteiden erillään pitäminen tekee johtopäätöksestä puolustettavan tarkastuksessa.