Jarraitu DNS kontsulta jauzi batetik bestera benetako iturria aurkitzeko
Bezeroari emandako resolver helbideak ez du zehazten resolverrak zein iturri ikusiko duen. Jarraitu bezeroa, birbidaltzailea eta jasotzen duen zerbitzaria, eta idatzi bidea.
Bezeroari resolver helbide bat emateak zehazten du nora bidaltzen diren kontsultak, ez resolverrak zein iturri ikusiko duen. Bideratzeak, birbidaltzeak eta itzulpenak txanda bana dute bi muturren artean. Iturri-galderezko runbook batek kontsultari jauzi batetik bestera jarraitzen dio eta behatzaile bakoitzak benetan zer ikusi zuen erregistratzen du. Ordenak garrantzia du, behaketaren aurretik egindako baieztapena formatu hobeagoko susmo bat besterik ez delako.
Idatzi antolaketa ebidentzia bildu aurretik
Lau lekuk zerbait esan dezakete DNS iturri bati buruz, eta ez dute denek gauza bera esaten. Bezeroaren nukleoak badaki zein iturri erabiliko lukeen, birbidaltzaileak badaki zer bidali zuen gorako norabidean, itzultzen duen gailuak badaki zer berridatzi zuen, eta jasotzen duen resolverrak badaki zer iritsi zen. Idatzi horietatik zein iritsi zaitezkeen benetan ezer bildu aurretik.
| 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 |
Idatzi zure itxaropena ere, uste duzun erabileran dagoen resolverra barne. Bide zatitu batek kontsulta erabat beste toki batera bidal dezake, eta cache batek gorako trukeketarik gabe erantzun dezake, beraz buruan soilik gordetzen den hipotesiak ez du lehen ustekabea gaindituko. Eduki ezazu adierazitako diseinua eta behatutako bidea ohar beraren zutabe bereizietan; biak bat ez datozenean, atzetik jarraitzea merezi duen galdera aurkitu duzu.
Egiaztatu zein prozesuk bidali zuen kontsulta benetan
Hasi bezeroan: erregistratu resolver helbidea, kontsultaren izena eta ordua, eta egiaztatu ondoren zein prozesuk bidali zuen. Beheko lehen lerroak UDP socket-a duen prozesua izendatzen du, eta hori da izenburu honek agintzen duen egiaztapena. Prozesu hori nabigatzailearen laguntzaile bat edo edukiontzi runtime bat bada sistemaren resolverraren ordez, arrastoaren gainerakoak inork eskatu gabeko bide bat deskribatzen du.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Hainbat interfaze dituen ostalari batean, jakin itzazu lehenengo kernelak helmuga horretarako zein iturburu helbide aukeratzen duen beste inora begiratu aurretik. Hori da bidea erabat zure kontrolpean dagoen azken puntua, eta resolverrak jakinarazten duenarekin alderatuko duzun balioa da. Desadostasuna zerbait tartean paketea berridatzi izanaren edo bi kontsulta desberdin bidali izanaren seinalea da.
Eduki proba-izenak barnekoak, resolver publiko batera bidalitako barne-izen batek ez baitu ezer frogatzen barne-bideaz eta argitaratu behar ez zenuen izen bat argitaratzen baitu. DNS segurua gaituta duen nabigatzaile bat ez da socket zerrenda horretan agertuko, eta absentzia hori bera da erantzuna.
Birbidaltzaileak bigarren kontsulta bat egiten du, bereizia
Birbidaltzaile batek truke bat bihurtzen du bi. Beheranzko eskaera iristen da, eta birbidaltzaileak bere kontsulta propioa bidaltzen du gora, aukeratzen duen helbide batetik. Bere konfigurazioak, ez bezeroak, zehazten du gorako resolverrak zer ikusten duen.
dnsmasq eskuliburua irakurtzea merezi du horregatik: birbidaltzaileak nola aukeratzen dituen gorako zerbitzariak eta nola lotzen duen entzuteko aldea dokumentatzen du, eta antolaketa horretan ezerk ez du bezeroaren iturburua gora eramaten. Beraz, gateway helbide bat erakusten duen resolver log bat normala da, ez da akats baten froga. Absentzia bezain erraza da oker irakurtzen, cache hit batek ez baitu gorako kontsultarik sortzen eta inoiz iritsi ez zen kontsulta baten berdin ikusten baitu. Irakurri birbidaltzailearen konfigurazioa eta haren cache egoera bi ondorioetako bat atera aurretik. Bi galdera, bi leku begiratzeko.
Irakurri iturria jasotzen duen resolverrean
Hori argitzen duen behaketa bakarra zerbitzari aldean egiten da. Bezeroaren interfaze zerrendatik ondorioztatzen dena hipotesi bat da resolverrak benetan zer iritsi zen jakinarazi arte.
tcpdump -ni any port 53 and host 10.20.30.53Hartu arrastoa resolver ostalarian, eduki arrastoa labur eta mugatuta, eta gorde politikak uzten duen lekuan. Behatutako iturria helbide itzulia bada, hurrengo galdera zein gailuk egin zuen itzulpena eta haren politika nahi dena den da. Arrasto batek zer iritsi zen erantzuten du; ez du azaltzen zergatik baimendu zuen politikak. Aipa behatzailea eta jauzia oharrean, gateway bati buruzko pribatutasun baieztapen bat jauzi horri buruzkoa baita, ez bide osoari buruzkoa.
Idatzi aurkikuntza bide gisa, ez helbide gisa
Erregistratu bezeroa, resolverra, edozein birbidaltzaile, jauzi bakoitzean behatutako iturburua eta hura gobernatzen duen politika. Erregistro horrek etorkizuneko galdera gehienak erantzuten ditu beste arrastorik gabe. Marraztu kate gisa, helbide zerrenda batek ezkutatzen baitu zein jauzik sortu zuen zein.
Erantsi data, bezeroaren bertsioa eta konfigurazioaren berrikuspena marrazkira, geroagoko irakurle batek oraindik balio duen jakin dezan. Bereizi garraioaren iturburua zerbitzuak prozesatzen duen gainerako guztiatik, gateway helbide bat ikusteak ez baitu ezer esaten beste zer gordetzen den. Resolverren kokapenak ere ez du ezer esaten zein bezerok galdetu zuen. Baieztapen horiek bereiz edukitzea da ondorioa berrikuspenean defendagarri egiten duena.