پرس‌وجوی 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روی میزبان ریزولور ثبت کنید، ثبت را کوتاه و محدود نگه دارید و آن را جایی ذخیره کنید که سیاست اجازه می‌دهد. اگر منبع مشاهده‌شده نشانی ترجمه‌شده باشد، پرسش بعدی این است که کدام دستگاه ترجمه را انجام داده و آیا سیاست آن همان سیاست موردنظر است. ثبت به این پاسخ می‌دهد که چه رسید؛ توضیح نمی‌دهد چرا سیاست آن را مجاز دانست. ناظر و گام را در یادداشت نام ببرید، چون ادعای حریم خصوصی دربارهٔ یک دروازه ادعایی دربارهٔ همان گام است و نه دربارهٔ کل مسیر.
یافته را به‌صورت مسیر بنویسید، نه نشانی
کلاینت، ریزولور، هر فورواردر، منبع مشاهده‌شده در هر گام و سیاستی که آن را اداره می‌کند را ثبت کنید. چنین سندی به بیشتر پرسش‌های آینده بدون ثبت دیگری پاسخ می‌دهد. آن را زنجیره‌ای بکشید، چون فهرستی از نشانی‌ها پنهان می‌کند که کدام گام کدام را تولید کرده است.
تاریخ، نسخهٔ کلاینت و بازبینی پیکربندی را به نقشه بچسبانید تا خوانندهٔ بعدی بتواند بگوید آیا هنوز معتبر است. منبع انتقال را از هر چیز دیگری که سرویس پردازش می‌کند جدا کنید، چون دیدن نشانی دروازه هیچ نمی‌گوید دربارهٔ اینکه چه چیز دیگری نگه داشته می‌شود. مکان ریزولور هم هیچ نمی‌گوید دربارهٔ اینکه کدام کلاینت پرسیده است. جدا نگه داشتن این ادعاها همان چیزی است که نتیجه را در بازبینی قابل دفاع می‌کند.