محتوای آموزشی وبلاگ نت‌آرام
رکورد ساده دامنه پاسخ می‌دهد، اما گاهی رکوردهای بزرگ‌تر مثل بعضی پاسخ‌های DNSSEC یا TXT باز نمی‌شوند. یکی از علت‌های ممکن این است که پاسخ UDP در یک بسته جا نمی‌شود، سرور آن را با علامت «ناقص» برمی‌گرداند و مشتری باید همان درخواست را از مسیر TCP تکرار کند؛ اگر TCP پورت ۵۳ در مسیر مجاز نباشد، مرحله دوم شکست می‌خورد.
این اتفاق برای هر رکورد بزرگ و هر timeout رخ نمی‌دهد. در این راهنما ابتدا دو مسیر UDP و TCP را با یک درخواست مشخص مقایسه می‌کنیم، بعد محل مشکل را بین سرویس DNS، فایروال و شبکه پیدا می‌کنیم. مثال‌ها برای مدیری هستند که مجاز است سرور DNS و شبکه مربوط را بررسی کند.
آدرس
203.0.113.10، دامنه example.com و شبکه 192.0.2.0/24 فقط نمونه‌اند. آن‌ها را با IP واقعی سرور DNS، دامنه تحت مدیریت خود و شبکه مشتریان مجاز عوض کنید. دسترسی کنسول و یک نشست مدیریتی باز را پیش از تغییر فایروال در اختیار داشته باشید.۱. ابتدا سرور DNS درست را مشخص کنید
اگر می‌خواهید پاسخ یک nameserver معتبر برای دامنه خود را ببینید، از رایانه مشتری یا سرور آزمایشی:
کد / دستورdig NS example.com +short
نام دامنه واقعی خود را جایگزین کنید. این دستور nameserverهایی را که از مسیر resolver فعلی دیده می‌شوند نشان می‌دهد؛ برای عیب‌یابی کامل، آدرس هر nameserver و تنظیمات ثبت دامنه را با اطلاعات رسمی خود تطبیق دهید. اگر
dig نصب نیست، در Ubuntu معمولاً در بسته dnsutils و در AlmaLinux معمولاً در بسته bind-utils قرار دارد؛ نصب را از مخزن سالم و مجاز انجام دهید.IP واقعی یکی از سرورهای مجاز را انتخاب کنید. اگر سرور شما یک resolver خصوصی است، آزمون را فقط از مشتری مجاز همان شبکه انجام دهید. باز کردن دسترسی بازگشتی برای کل اینترنت می‌تواند سرور را در معرض سوءاستفاده قرار دهد.
۲. یک پاسخ ساده UDP و TCP را مقایسه کنید
برای یک رکورد واقعی دامنه خود:
کد / دستورdig @203.0.113.10 example.com A +norecurse +time=2 +tries=1
این نمونه مستقیماً از IP مشخص‌شده و بدون درخواست recursion می‌پرسد. در خروجی،
status، بخش پاسخ و زمان را بخوانید. برای پاسخ authoritative معمولاً انتظار علامت aa دارید؛ نتیجه به نقش سرور و نوع رکورد بستگی دارد.حالا همان درخواست را با TCP بفرستید:
کد / دستورdig @203.0.113.10 example.com A +norecurse +tcp +time=2 +tries=1
اگر UDP پاسخ می‌دهد ولی TCP timeout یا اتصال ردشده می‌دهد، یکی از علت‌های محتمل مسیر یا گوش ندادن TCP پورت ۵۳ است. اگر هر دو درست پاسخ می‌دهند، هنوز باید همان رکورد بزرگی را که در کار واقعی مشکل دارد هم آزمایش کنید.
NOERROR به‌تنهایی وجود رکورد موردنظر را ثابت نمی‌کند؛ بخش پاسخ و نوع داده را نیز ببینید.۳. علامت TC را عمداً ببینید
اگر دامنه شما DNSSEC دارد و پاسخ
کد / دستورDNSKEY آن بزرگ است، نمونه زیر یک بافر UDP کوچک درخواست می‌کند:dig @203.0.113.10 example.com DNSKEY +dnssec +bufsize=512 +ignore +norecurse +time=2 +tries=1
+ignore در این آزمایش جلوی تلاش خودکار dig برای ادامه با TCP پس از دریافت پاسخ ناقص را می‌گیرد تا پاسخ UDP را ببینید. در خط flags به tc دقت کنید. وجود tc یعنی پاسخ کامل در آن پیام UDP جا نشده است. اگر پاسخ کوچک باشد، سرور DNSSEC نداشته باشد یا سرور از روش دیگری پاسخ دهد، ممکن است tc نبینید؛ نبودن آن به‌تنهایی سلامت همه پاسخ‌های بزرگ را ثابت نمی‌کند.همین پرسش را صریحاً با TCP تکرار کنید:
کد / دستورdig @203.0.113.10 example.com DNSKEY +dnssec +tcp +norecurse +time=2 +tries=1
اگر UDP علامت
tc دارد و TCP پاسخ کامل می‌دهد، مسیر بازگشت به TCP برای آن آزمایش کار می‌کند. اگر UDP علامت tc دارد ولی TCP شکست می‌خورد، سراغ مرحله بعد بروید. اگر UDP هیچ پاسخی نمی‌دهد، آن را با پاسخ دارای tc یکی نگیرید؛ افت بسته، فایروال، اندازه بسته یا مسیر شبکه نیز ممکن است علت باشند.در اجرای معمول بدون
کد / دستور+ignore، dig ممکن است پس از دریافت پاسخ ناقص خودکار TCP را امتحان کند و پیام تغییر مسیر را نشان دهد. برای دیدن رفتار معمول:dig @203.0.113.10 example.com DNSKEY +dnssec +bufsize=512 +norecurse +time=2 +tries=1
هدف از
512 تشخیص است، نه توصیه برای تنظیم دائمی همه سرورها. خاموش کردن DNSSEC یا تغییر بی‌بررسی اندازه بسته، راه‌حل عمومی این مشکل نیست.۴. آیا خود سرویس روی TCP گوش می‌دهد؟
روی سرور DNS با حساب مدیر:
کد / دستورsudo ss -lntup '( sport = :53 )'
برای آدرس مورد انتظار به سطرهای TCP و UDP توجه کنید. اگر سرویس فقط روی
127.0.0.1 یا 127.0.0.53 گوش می‌دهد، این به معنی گوش دادن روی IP عمومی نیست. اگر فقط UDP دیده می‌شود، تنظیم listen و وضعیت سرویس DNS را مطابق نرم‌افزار خود اصلاح کنید.نام سرویس را با وضعیت سیستم پیدا کنید. برای نمونه، در نصب‌هایی که BIND با نام
کد / دستورnamed اجرا می‌شود:sudo systemctl status named --no-pager -l
در Ubuntu ممکن است نام سرویس
کد / دستورbind9 باشد. سپس گزارش سرویس واقعی را ببینید:sudo journalctl -u named --since '30 minutes ago' --no-pager
اگر نام سرویس شما
bind9 است، همان را جایگزین کنید. خطای bind، نبودن مجوز یا پیکربندی نادرست نیاز به اصلاح همان نرم‌افزار دارد. پیش از تغییر پورت یا restart، نقش سرور و سایر سرویس‌های وابسته را مشخص کنید.از خود سرور هم IP درستِ قابل دسترسی آن را امتحان کنید:
کد / دستورdig @127.0.0.1 example.com DNSKEY +dnssec +tcp +norecurse +time=2 +tries=1
این تست فقط وقتی معنی دارد که سرویس روی loopback پاسخ می‌دهد. اگر TCP محلی موفق ولی از مشتری مجاز ناموفق است، فایروال میزبان، فایروال ارائه‌دهنده و مسیر بین دو دستگاه را جداگانه بررسی کنید. اگر TCP محلی هم شکست می‌خورد، ابتدا خود سرویس و تنظیم listen را برطرف کنید.
۵. فایروال را محدود و هدفمند اصلاح کنید
در سروری که از UFW استفاده می‌کند، وضعیت فعلی را ببینید:
کد / دستورsudo ufw status numbered
اگر سرویس یک resolver خصوصی است و فقط شبکه نمونه
کد / دستور192.0.2.0/24 باید به IP نمونه DNS دسترسی داشته باشد، پس از جایگزینی آدرس‌ها و نام رابط تأییدشده، یک قانون محدود برای TCP می‌تواند چنین باشد:sudo ufw allow in on ens3 proto tcp from 192.0.2.0/24 to 203.0.113.10 port 53
برای UDP نیز اگر قانون مجاز مناسب وجود ندارد:
کد / دستورsudo ufw allow in on ens3 proto udp from 192.0.2.0/24 to 203.0.113.10 port 53
این‌ها مثال‌اند؛
ens3، شبکه مبدأ و IP مقصد باید دقیقاً با محیط شما تطبیق داده شوند. از دستورهای عمومی باز کردن پورت برای همه، بدون شناخت نقش سرویس استفاده نکنید. برای nameserver عمومی authoritative ممکن است لازم باشد مشتریان اینترنتی بتوانند هر دو پروتکل را ببینند، اما recursion و دسترسی‌های مدیریتی همچنان باید محدود شوند. ترتیب و قوانین موجود UFW و نیز فایروال شبکه ارائه‌دهنده می‌توانند بر نتیجه اثر بگذارند.پس از تغییر، دوباره
sudo ufw status numbered را ببینید و آزمون dig +tcp را از همان مشتری مجاز تکرار کنید. فقط اضافه شدن قانون به فهرست، عبور واقعی ترافیک را ثابت نمی‌کند. UFW را بدون بررسی قوانین SSH و راه دسترسی جایگزین فعال یا reset نکنید. در AlmaLinux ممکن است firewalld یا فایروال دیگری استفاده شود؛ قانون معادل را با محدوده مبدأ و مقصد درست در همان ابزار و منطقه فعال تنظیم و از بیرون آزمایش کنید.۶. اگر هر دو مسیر باز است اما بعضی پاسخ‌ها باز هم گیر می‌کنند
یک درخواست UDP با اندازه رایج‌تر نیز آزمایش کنید:
کد / دستورdig @203.0.113.10 example.com DNSKEY +dnssec +bufsize=1232 +norecurse +time=2 +tries=1
اگر پاسخ کوچک کار می‌کند ولی UDP بزرگ timeout می‌دهد و TCP سالم است، اندازه پاسخ، قطعه‌قطعه شدن بسته و تجهیزات میان راه می‌توانند نقش داشته باشند. برای تشخیص، زمان، IPهای مبدأ و مقصد و نتیجه هر آزمایش را ثبت کنید. تنظیم دائمی EDNS یا MTU به شبکه و نرم‌افزار شما بستگی دارد و باید بر اساس اندازه‌گیری انجام شود.
اگر جواب از یک nameserver درست و از دیگری غلط است، هرکدام را جداگانه با همان رکورد آزمایش کنید و هماهنگی zone، نسخه داده و وضعیت سرویس‌ها را بررسی کنید. پس از اصلاح، یک بار از resolver واقعی کاربران و یک بار مستقیم از nameserver پرس‌وجو کنید؛ اثر کش ممکن است باعث شود نتیجه قدیمی مدتی دیده شود.
این مشکل می‌تواند روی سرویس DNSِ سرور مجازی ایران یا سرور اختصاصی ایران رخ دهد. برای آشنایی با اثر DNSSEC در تغییر nameserver، راهنمای مهاجرت nameserver و DNSSEC را ببینید. نیاز DNS به TCP در مستند مایکروسافت درباره پورت‌های DNS و RFC 7766 توضیح داده شده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام