Folch de DNS-fraach hop foar hop om de echte boarne te finen
In trochstjoerd resolveradres bepaalt net hokker boarne de resolver sjocht. Folch de klient, de trochstjoerder en de ûntfangende tsjinner en skriuw it paad op.
In klient in resolveradres jaan bepaalt wêr't fragen hinne gean, net hokker boarne de resolver sjocht. Rûtelearring, trochstjoeren en oersetting krije elk in beurt tusken de beide einen. In runbook foar boarnevragen folget de fraach hop foar hop en skriuwt op wat elke waarnimmer wier seach. De oarder makket út, want in bewearing foar de waarnimming is mar in gissing mei bettere opmaak.
Skriuw de opbou op foardatst bewiis sammelst
Fjouwer plakken kinne dy wat oer in DNS-boarne fertelle, en se fertelle net allegear itselde. De klientkern wit hokker boarne er brûke soe, in trochstjoerder wit wat er streamop stjoerd hat, in oersettend apparaat wit wat it weromskreaun hat, en de ûntfangende resolver wit wat oankommen is. Skriuw op hokker fan dy'tsto wier berikke kinst foardatst eat sammelst.
| 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 |
Skriuw ek dyn ferwachting op, ynklusyf de resolver dêr'tst fan tinkst dat er yn gebrûk is. In splitrûte kin in fraach hiel earne oars hinne stjoere, en in cache kin antwurdzje sûnder hokker streamop-útwikseling ek, dus in oanname dy't allinnich yn it ûnthâld holden wurdt, oerlibbet de earste ferrassing net. Hâld it oanjûne ûntwerp en it waarnommen paad yn aparte kolommen fan deselde notysje; as de beide it net iens binne, hast de fraach fûn dy't it efterfolgjen wurdich is.
Kontrolearje hokker proses de fraach wier stjoerd hat
Begjin by de klient: skriuw it resolveradres, de fraachnamme en de tiid op en befêstigje dan hokker proses it stjoerd hat. De earste rigel hjirûnder neamt it proses dat de UDP-socket hâldt, en dat is de kontrôle dy't dizze kop belooft. As dat proses in browserhelper of in containerruntime is ynstee fan de systeemresolver, dan beskriuwt de rest fan it spoar in paad dêr't nimmen om frege hat.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Sykje op in host mei ferskate ynterfaces earst út hokker boarneadres de kernel foar dat bestimming kiest foardatsto earne oars sjochst. Dat is it lêste punt wêrop it paad hielendal ûnder dyn kontrôle is, en it is de wearde dy'tst fergelykst mei wat de resolver meldt. In ferskil is it sinjaal dat eat tuskenyn it pakket weromskreaun hat, of dat der twa ferskillende fragen stjoerd binne.
Hâld de testnammen yntern, want in ynterne namme dy't nei in iepenbiere resolver stjoerd wurdt, bewiist neat oer it ynterne paad en publisearret in namme dy'tst net publisearje hoegde. In browser mei feilige DNS oan sil hielendal net yn dy socketlist ferskine, en dat ûntbrekken is sels it antwurd.
De trochstjoerder docht in twadde, aparte fraach
In trochstjoerder makket fan ien útwikseling twa. It streamôf-fersyk komt oan, en de trochstjoerder stjoert dan syn eigen fraach streamop fan in adres dat er kiest. Syn konfiguraasje, net de klient, bepaalt wat de streamop-resolver sjocht.
De dnsmasq-hânlieding is om dy reden it lêzen wurdich: it dokumintearret hoe't in trochstjoerder streamop-tsjinners kiest en syn harkkant bynt, en neat yn dy opbou draacht de klientboarne streamop. In resolverlog dy't in gateway-adres toant, is dus normaal ynstee fan bewiis fan in flater. Ofwêzigens is like maklik ferkeard te lêzen, want in cachetrof leveret gjin streamop-fraach op en liket identyk op in fraach dy't nea oankaam. Lês de konfiguraasje fan de trochstjoerder en syn cachestatus foardatst ien fan de beide konklúzjes lûkst. Twa fragen, twa plakken om te sjen.
Lês de boarne by de ûntfangende resolver
De iennige waarnimming dy't dit beslist, wurdt oan de tsjinnerkant dien. Alles wat út 'e ynterfacelist fan 'e klient ôflaat wurdt, bliuwt in hypoteze oant de resolver meldt wat wier oankommen is.
tcpdump -ni any port 53 and host 10.20.30.53Meitsje opnames op de resolverhost, hâld de opname koart en beheind, en bewarje him wêr't belied it talit. Is de waarnommen boarne in oerset adres, dan is de folgjende fraach hokker apparaat de oersetting dien hat en oft syn belied it bedoelde is. In opname antwurdet wat oankommen is; it ferklearret net wêrom't it belied it talitten hat. Neam de waarnimmer en de hop yn 'e notysje, want in privacybewearing oer in gateway is in bewearing oer dy hop ynstee fan oer it hiele paad.
Skriuw de befinning as in paad, net as in adres
Skriuw de klient, de resolver, elke trochstjoerder, de waarnommen boarne by elke hop en it belied dat dy regelet op. Dat rekord antwurdet de measte takomstige fragen sûnder noch in opname. Tekenje it as in keatling, want in list fan adressen ferberget hokker hop hokker ien opsmiten hat.
Heechst de datum, de klientferzje en de konfiguraasje-revysje oan 'e tekening, sadat in lettere lêzer sjen kin oft dy noch jildt. Skied de ferfierboarne fan al it oare dat de tsjinst ferwurket, want in gateway-adres sjen seit neat oer wat oars bewarre wurdt. In resolverlokaasje seit likegoed neat oer hokker klient frege hat. It apart hâlden fan dy bewarings is wat de konklúzje ûnder resinsje ferdigenber makket.