Jälgige DNS-päringut samm-sammult, et leida tõeline allikas
Peale surutud resolveri aadress ei otsusta, millist allikat resolver näeb. Jälgige klienti, edastajat ja vastuvõtvat serverit ning kirjutage tee üles.
Kliendile resolveri aadressi andmine määrab, kuhu päringud lähevad, mitte seda, millist allikat resolver näeb. Marsruutimine, edastamine ja tõlkimine saavad igaüks oma korra kahe otsa vahel. Allika küsimuste käsiraamat järgib päringut samm-sammult ja märgib üles, mida iga vaatleja tegelikult nägi. Järjekord on oluline, sest enne vaatlust tehtud väide on vaid paremini vormindatud oletus.
Kirjutage paigutus üles enne tõendite kogumist
Neli kohta võivad DNS-allika kohta midagi öelda ja kõik ei ütle sama. Kliendi tuum teab, millist allikat see kasutaks, edastaja teab, mida see ülespoole saatis, tõlkiv seade teab, mida see ümber kirjutas, ja vastuvõttev resolver teab, mis saabus. Kirjutage üles, millisteni te tegelikult pääsete, enne kui midagi kogute.
| 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 |
Kirjutage üles ka oma ootus, sealhulgas resolver, mis teie arvates kasutusel on. Jaotatud marsruut võib saata päringu hoopis mujale ja vahemälu võib vastata ilma ühegi ülespoole suunatud vahetuseta, seega ainult mälus hoitav eeldus ei ela üle esimest üllatust. Hoidke deklareeritud kavand ja vaadeldud tee sama märkme eraldi veergudes; kui need kaks ei klapi, olete leidnud küsimuse, mida tasub jälgida.
Kontrollige, milline protsess päringu tegelikult saatis
Alustage kliendist: kirjutage üles resolveri aadress, päringu nimi ja aeg, seejärel kinnitage, milline protsess selle saatis. Esimene rida allpool nimetab protsessi, mis hoiab UDP-pesast, ja see on kontroll, mida see pealkiri lubab. Kui see protsess on brauseri abiline või konteineri käituskeskkond, mitte süsteemi resolver, kirjeldab ülejäänud jälg teed, mida keegi ei küsinud.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Mitme liidesega hostis tehke esmalt kindlaks, millise lähteaadressi tuum selle sihtkoha jaoks valib, enne kui vaatate kuhugi mujale. See on viimane punkt, kus tee on täielikult teie kontrolli all, ja see on väärtus, mida võrdlete resolveri teatatuga. Erinevus on märk sellest, et miski vahepeal kirjutas paketi ümber või saadeti kaks erinevat päringut.
Hoidke testnimed sisemised, sest avalikule resolverile saadetud sisemine nimi ei tõesta sisemise tee kohta midagi ja avaldab nime, mida te ei pidanud avaldama. Turvalise DNS-iga brauser ei ilmu selles pesade loendis üldse ja see puudumine on ise vastus.
Edastaja teeb teise, eraldi päringu
Edastaja muudab ühe vahetuse kaheks. Allpoolt tulev taotlus saabub ja seejärel saadab edastaja oma päringu ülespoole enda valitud aadressilt. Tema konfiguratsioon, mitte klient, otsustab, mida ülemine resolver näeb.
dnsmasqi käsiraamat on just sel põhjusel lugemist väärt: see dokumenteerib, kuidas edastaja valib ülemisi servereid ja seob oma kuulamispoole, ja miski selles paigutuses ei kanna kliendi allikat ülespoole. Seetõttu on lüüsi aadressi näitav resolveri logi normaalne, mitte rikke tõend. Puudumist on sama lihtne valesti lugeda, sest vahemälu tabamus ei tekita ühtegi ülespoole suunatud päringut ja näeb välja täpselt nagu päring, mis kunagi ei saabunud. Lugege edastaja konfiguratsiooni ja selle vahemälu olekut enne, kui teete kummagi järelduse. Kaks küsimust, kaks kohta, kuhu vaadata.
Lugege allikat vastuvõtvas resolveris
Ainus vaatlus, mis selle lahendab, tehakse serveri poolel. Kõik, mis tuletatakse kliendi liideste loendist, jääb hüpoteesiks, kuni resolver teatab, mis tegelikult saabus.
tcpdump -ni any port 53 and host 10.20.30.53Salvestage resolveri hostis, hoidke salvestus lühike ja piiratud ning hoiustage seda seal, kus poliitika lubab. Kui vaadeldud allikas on tõlgitud aadress, on järgmine küsimus, milline seade tõlkimise tegi ja kas selle poliitika on kavandatud. Salvestus vastab, mis saabus; see ei selgita, miks poliitika selle lubas. Nimetage vaatleja ja samm märkmes, sest lüüsi puudutav privaatsusväide käib selle sammu, mitte kogu tee kohta.
Kirjutage leid üles teena, mitte aadressina
Kirjutage üles klient, resolver, iga edastaja, vaadeldud allikas igal sammul ja seda juhtiv poliitika. Selline kirje vastab enamikule tulevastele küsimustele ilma uue salvestuseta. Joonistage see ahelana, sest aadresside loend varjab, milline samm andis millise.
Lisage joonisele kuupäev, kliendi versioon ja konfiguratsiooni redaktsioon, et hilisem lugeja saaks öelda, kas see kehtib veel. Eraldage transpordiallikas kõigest muust, mida teenus töötleb, sest lüüsi aadressi nägemine ei ütle midagi selle kohta, mida veel hoitakse. Ka resolveri asukoht ei ütle midagi selle kohta, milline klient küsis. Just nende väidete eraldamine teeb järelduse ülevaatamisel kaitstavaks.