Нақты көзді табу үшін DNS сұрауын қадам сайын қадағалаңыз
Таңылған резолвер мекенжайы резолвер қай көзді көретінін шешпейді. Клиентті, форвардерді және қабылдаушы серверді қадағалап, жолды жазып алыңыз.
Клиентке резолвер мекенжайын беру сұраулардың қайда жіберілетінін анықтайды, резолвер қай көзді көретінін емес. Маршруттау, жіберу және аудару екі ұштың арасында кезек-кезек іске қосылады. Көз туралы сұрақтарға арналған нұсқаулық сұрауды қадам сайын қадағалайды және әр бақылаушының шын мәнінде нені көргенін жазады. Тәртіп маңызды, өйткені бақылауға дейін айтылған тұжырым тек жақсырақ форматталған болжам.
Дәлелдер жинамас бұрын орналасуды жазыңыз
Төрт орын DNS көзі туралы сізге бірдеңе айта алады және олардың барлығы бірдей нәрсе айтпайды. Клиент ядросы қай көзді қолданатынын біледі, форвардер жоғарыға нені жібергенін біледі, аударатын құрылғы нені қайта жазғанын біледі, ал қабылдаушы резолвер ненің келгенін біледі. Бірдеңе жинамас бұрын олардың қайсысына шын мәнінде жете алатыныңызды жазыңыз.
| 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 |
Күтуіңізді де жазыңыз, қолданыста деп ойлайтын резолвер-ді қоса. Бөлінген маршрут сұрауды мүлдем басқа жерге жібере алады, ал кэш жоғарыға ешқандай алмасусыз жауап бере алады, сондықтан тек жадыда ұсталатын болжам бірінші тосынсыйдан өтпейді. Жарияланған жобаны және бақыланған жолды бір жазбаның бөлек бағандарында ұстаңыз; екеуі сәйкес келмесе, соңына түсуге тұрарлық сұрақты таптыңыз.
Сұрауды шын мәнінде қай процесс жібергенін тексеріңіз
Клиенттен бастаңыз: резолвер мекенжайын, сұрау атын және уақытты жазып, содан кейін қай процестің жібергенін растаңыз. Төмендегі бірінші жол UDP сокетін ұстайтын процесті атайды және бұл осы тақырып уәде еткен тексеріс. Егер бұл процесс жүйелік резолвер орнына браузер көмекшісі немесе контейнер орындау ортасы болса, іздің қалған бөлігі ешкім сұрамаған жолды сипаттайды.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Бірнеше интерфейсі бар хостта басқа жерге қарамас бұрын ядроның сол тағайындалған жер үшін қай көз мекенжайын таңдайтынын анықтаңыз. Бұл жол толық сіздің бақылауыңызда болатын соңғы нүкте және резолвер хабарлағанмен салыстыратын мән. Сәйкессіздік арадағы бірдеңенің пакетті қайта жазғанының немесе екі түрлі сұрау жіберілгенінің белгісі.
Тест атауларын ішкі күйде ұстаңыз, өйткені ашық резолвер-ге жіберілген ішкі атау ішкі жол туралы ештеңе дәлелдемейді және жариялаудың қажеті жоқ атауды жариялайды. Қауіпсіз DNS қосулы браузер сол сокет тізімінде мүлдем көрінбейді және сол жоқтық өзі жауап.
Форвардер екінші, бөлек сұрау жасайды
Форвардер бір алмасуды екіге айналдырады. Төменнен сұраныс келеді, содан кейін форвардер өз сұрауын өзі таңдаған мекенжайдан жоғары жібереді. Жоғарғы резолвер нені көретінін клиент емес, оның конфигурациясы шешеді.
dnsmasq нұсқаулығы дәл осы себеппен оқуға тұрарлық: ол форвардердің жоғарғы серверлерді қалай таңдайтынын және өзінің тыңдау жағын қалай байланыстыратынын құжаттайды, ал бұл орналасуда ештеңе клиент көзін жоғары алып жүрмейді. Сондықтан шлюз мекенжайын көрсететін резолвер журналы қалыпты, ақау дәлелі емес. Жоқтықты да дәл солай оңай қате оқуға болады, өйткені кэш соққысы жоғарыға ешқандай сұрау тудырмайды және ешқашан келмеген сұрауға дәл ұқсайды. Екі қорытындының бірін шығармас бұрын форвардер конфигурациясын және оның кэш күйін оқыңыз. Екі сұрақ, қарайтын екі орын.
Көзді қабылдаушы резолвер-де оқыңыз
Мұны шешетін жалғыз бақылау сервер жағында алынады. Клиент интерфейстерінің тізімінен шығарылғанның бәрі резолвер шын мәнінде ненің келгенін хабарлағанша болжам болып қалады.
tcpdump -ni any port 53 and host 10.20.30.53Резолвер хостта түсіріңіз, түсіруді қысқа және шектеулі ұстаңыз және саясат рұқсат ететін жерде сақтаңыз. Егер бақыланған көз аударылған мекенжай болса, келесі сұрақ аударманы қай құрылғы жасағаны және оның саясаты көзделген бе. Түсіру ненің келгенін жауаптайды; саясаттың неге рұқсат еткенін түсіндірмейді. Жазбада бақылаушыны және қадамды атаңыз, өйткені шлюз туралы құпиялылық тұжырымы сол қадам туралы, бүкіл жол туралы емес.
Табылғанды мекенжай ретінде емес, жол ретінде жазыңыз
Клиентті, резолвер-ді, кез келген форвардерді, әр қадамдағы бақыланған көзді және оны басқаратын саясатты жазыңыз. Мұндай жазба болашақ сұрақтардың көбісіне жаңа түсірусіз жауап береді. Оны шынжыр ретінде сызыңыз, өйткені мекенжайлар тізімі қай қадам қайсысын бергенін жасырады.
Сызбаға күнді, клиент нұсқасын және конфигурация ревизиясын қосыңыз, сонда кейінгі оқырман оның әлі де күшінде екенін айта алады. Тасымалдау көзін қызмет өңдейтін қалғанның бәрінен бөліңіз, өйткені шлюз мекенжайын көру тағы ненің сақталатыны туралы ештеңе айтпайды. Резолвер орны да қай клиент сұрағаны туралы ештеңе айтпайды. Осы тұжырымдарды бөлек ұстау қорытындыны тексеруде қорғауға болатын етеді.