Прослідкуйте запит 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Знімайте на хості резолвера, тримайте захоплення коротким і обмеженим і зберігайте його там, де дозволяє політика. Якщо спостережуване джерело — трансльована адреса, наступне питання: який пристрій виконав трансляцію і чи його політика є тією самою. Захоплення відповідає, що надійшло; воно не пояснює, чому політика це дозволила. Назвіть спостерігача й крок у нотатці, бо твердження про приватність щодо шлюзу стосується цього кроку, а не всього шляху.
Запишіть знахідку як шлях, а не як адресу
Запишіть клієнта, резолвер, будь-який форвардер, спостережуване джерело на кожному кроці та політику, що ним керує. Такий запис відповідає на більшість майбутніх питань без нового захоплення. Намалюйте його як ланцюг, бо список адрес приховує, який крок дав яку.
Додайте до схеми дату, версію клієнта й ревізію конфігурації, щоб пізніший читач міг сказати, чи вона ще діє. Відокремте транспортне джерело від усього іншого, що обробляє служба, бо вигляд адреси шлюзу нічого не каже про те, що ще зберігається. Місце резолвера теж нічого не каже про те, який клієнт запитував. Саме розділення цих тверджень робить висновок захищеним на перевірці.