Volg die DNS-navraag hop vir hop om die werklike bron te vind
’n Resolveradres wat aan ’n kliënt gegee word, bepaal nie watter bron die resolver sien nie. Volg die kliënt, die aanstuurder en die ontvangende bediener en skryf die pad neer.
Om aan ’n kliënt ’n resolveradres te gee, bepaal waar navrae gestuur word, nie watter bron die resolver sal sien nie. Roetering, aanstuur en vertaling kry elkeen ’n beurt tussen die twee punte. ’n Runbook vir bronvrae volg die navraag hop vir hop en teken op wat elke waarnemer werklik gesien het. Die volgorde maak saak, want ’n bewering wat voor die waarneming gemaak word, is net ’n raaiskoot met beter formatering.
Skryf die reëling neer voordat jy bewyse insamel
Vier plekke kan jou iets oor ’n DNS-bron vertel, en hulle sê nie almal dieselfde nie. Die kliëntkern weet watter bron dit sou gebruik, ’n aanstuurder weet wat hy stroomop gestuur het, ’n vertalende toestel weet wat dit herskryf het, en die ontvangende resolver weet wat aangekom het. Skryf neer watter van dié jy werklik kan bereik voordat jy enigiets insamel.
| 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 |
Skryf ook jou verwagting neer, insluitend die resolver wat jy glo in gebruik is. ’n Gesplete roete kan ’n navraag heeltemal elders heen stuur, en ’n kas kan antwoord sonder enige stroomop-uitruiling, so ’n aanname wat net in die geheue gehou word, oorleef nie die eerste verrassing nie. Hou die verklaarde ontwerp en die waargenome pad in aparte kolomme van dieselfde nota; wanneer die twee verskil, het jy die vraag gevind wat die moeite werd is om na te jaag.
Kyk watter proses het die navraag werklik gestuur
Begin by die kliënt: teken die resolveradres, die navraagnaam en die tyd op en bevestig dan watter proses dit gestuur het. Die eerste reël hieronder noem die proses wat die UDP-sok hou, en dit is die kontrole wat hierdie opskrif belowe. As daardie proses ’n blaaierhelper of ’n houerruntime is eerder as die stelselresolver, dan beskryf die res van die spoor ’n pad waarvoor niemand gevra het nie.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Op ’n gasheer met verskeie koppelvlakke, vind eers uit watter bronadres die kern vir daardie bestemming kies voordat jy elders kyk. Dit is die laaste punt waar die pad heeltemal onder jou beheer is, en dit is die waarde wat jy vergelyk met wat die resolver rapporteer. ’n Verskil is die sein dat iets tussenin die pakket herskryf het, of dat twee verskillende navrae gestuur is.
Hou die toetsname intern, want ’n interne naam wat na ’n openbare resolver gestuur word, bewys niks oor die interne pad nie en publiseer ’n naam wat jy nie nodig gehad het om te publiseer nie. ’n Blaaier met veilige DNS geaktiveer sal glad nie in daardie soklys verskyn nie, en daardie afwesigheid is self die antwoord.
Die aanstuurder maak ’n tweede, aparte navraag
’n Aanstuurder maak van een uitruiling twee. Die stroomaf-versoek kom aan, en die aanstuurder stuur dan sy eie navraag stroomop vanaf ’n adres wat hy kies. Sy konfigurasie, nie die kliënt nie, bepaal wat die stroomop-resolver sien.
Die dnsmasq-handleiding is om daardie rede die lees werd: dit dokumenteer hoe ’n aanstuurder stroomop-bedienerkies en sy luisterkant bind, en niks in daardie reëling dra die kliëntbron stroomop nie. ’n Resolverlog wat ’n gateway-adres wys, is dus normaal eerder as bewys van ’n fout. Afwesigheid is net so maklik om verkeerd te lees, want ’n kastreffer lewer geen stroomop-navraag nie en lyk identies aan ’n navraag wat nooit aangekom het nie. Lees die aanstuurderkonfigurasie en sy kastoestand voordat jy enige van die twee gevolgtrekkings maak. Twee vrae, twee plekke om te kyk.
Lees die bron by die ontvangende resolver
Die enigste waarneming wat dit beslis, word aan die bedienerkant gedoen. Enigiets wat uit die kliënt se koppelvlaklys afgelei word, bly ’n hipotese totdat die resolver rapporteer wat werklik aangekom het.
tcpdump -ni any port 53 and host 10.20.30.53Neem op op die resolver-gasheer, hou die opname kort en beperk, en bêre dit waar beleid dit toelaat. As die waargenome bron ’n vertaalde adres is, is die volgende vraag watter toestel die vertaling gedoen het en of sy beleid die bedoelde een is. ’n Opname beantwoord wat aangekom het; dit verduidelik nie waarom die beleid dit toegelaat het nie. Noem die waarnemer en die hop in die nota, want ’n privaatheidsbewering oor ’n gateway is ’n bewering oor daardie hop eerder as oor die hele pad.
Skryf die bevinding as ’n pad, nie ’n adres nie
Teken die kliënt, die resolver, enige aanstuurder, die waargenome bron by elke hop en die beleid wat dit beheer, op. Daardie rekord beantwoord die meeste toekomstige vrae sonder nog ’n opname. Teken dit as ’n ketting, want ’n lys adresse verberg watter hop watter een opgelewer het.
Heg die datum, die kliëntweergawe en die konfigurasie-hersiening aan die tekening, sodat ’n latere leser kan sien of dit nog geld. Skei die vervoerbron van alles anders wat die diens verwerk, want om ’n gateway-adres te sien sê niks oor wat anders bewaar word nie. ’n Resolverligging sê ook niks oor watter kliënt gevra het nie. Om daardie bewerings apart te hou, is wat die gevolgtrekking onder hersiening verdedigbaar maak.