Прасочце запыт 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Здымайце на хосце рэзалвера, трымайце захоп кароткім і абмежаваным і захоўвайце яго там, дзе дазваляе палітыка. Калі назіраная крыніца — трансляваны адрас, наступнае пытанне: якая прылада выканала трансляцыю і ці яе палітыка ёсць той самай. Захоп адказвае, што прыйшло; ён не тлумачыць, чаму палітыка гэта дазволіла. Назавіце назіральніка і крок у нататцы, бо сцвярджэнне пра прыватнасць адносна шлюза датычыць гэтага кроку, а не ўсяго шляху.
Запішыце знаходку як шлях, а не як адрас
Запішыце кліента, рэзалвер, любы форвардэр, назіраную крыніцу на кожным кроку і палітыку, якая ім кіруе. Такі запіс адказвае на большасць будучых пытанняў без новага захопу. Намалюйце яго як ланцуг, бо спіс адрасоў хавае, які крок даў які.
Дадайце да схемы дату, версію кліента і рэвізію канфігурацыі, каб позні чытач мог сказаць, ці яна яшчэ дзейнічае. Аддзяліце транспартную крыніцу ад усяго іншага, што апрацоўвае служба, бо выгляд адраса шлюза нічога не кажа пра тое, што яшчэ захоўваецца. Месца рэзалвера таксама нічога не кажа пра тое, які кліент запытваў. Менавіта раздзяленне гэтых сцвярджэнняў робіць выснову абароненай на праверцы.