پس از دو سال توسعه، کنسرسیوم ISC اولین نسخه پایدار یک شاخه جدید اصلی سرور DNS BIND 9.18 را منتشر کرد. پشتیبانی برای شعبه 9.18 به مدت سه سال تا سه ماهه دوم سال 2 به عنوان بخشی از یک چرخه پشتیبانی طولانی ارائه می شود. پشتیبانی از شعبه 2025 در ماه مارس و پشتیبانی از شعبه 9.11 در اواسط سال 9.16 به پایان می رسد. برای توسعه عملکرد نسخه پایدار بعدی BIND، یک شاخه آزمایشی BIND 2023 تشکیل شده است.
انتشار BIND 9.18.0 به دلیل اجرای پشتیبانی از DNS از طریق HTTPS (DoH, DNS over HTTPS) و DNS از طریق TLS (DoT, DNS over TLS) و همچنین مکانیزم XoT (XFR-over-TLS) قابل توجه است. برای انتقال امن محتوای DNS مناطق بین سرورها (هر دو منطقه ارسال و دریافت از طریق XoT پشتیبانی می شوند). با تنظیمات مناسب، یک فرآیند نام‌گذاری شده تنها می‌تواند نه تنها پرس‌و‌جوهای DNS سنتی، بلکه پرس‌وجوهایی را که با استفاده از DNS-over-HTTPS و DNS-over-TLS ارسال می‌شوند، ارائه دهد. پشتیبانی سرویس گیرنده برای DNS-over-TLS در ابزار dig تعبیه شده است، که می تواند برای ارسال درخواست ها از طریق TLS زمانی که پرچم "+tls" مشخص شده است، استفاده شود.
اجرای پروتکل HTTP/2 مورد استفاده در DoH بر اساس استفاده از کتابخانه nghttp2 است که به عنوان یک وابستگی اسمبلی اختیاری گنجانده شده است. گواهینامه های DoH و DoT می توانند توسط کاربر ارائه شوند یا به طور خودکار در زمان راه اندازی تولید شوند.
پردازش درخواست با استفاده از DoH و DoT با افزودن گزینه‌های "http" و "tls" به دستورالعمل گوش دادن فعال می‌شود. برای پشتیبانی از DNS-over-HTTP رمزگذاری نشده، باید "tls none" را در تنظیمات مشخص کنید. کلیدها در قسمت "tls" تعریف شده اند. پورت های شبکه پیش فرض 853 برای DoT، 443 برای DoH و 80 برای DNS-over-HTTP را می توان از طریق پارامترهای tls-port، https-port و http-port لغو کرد. مثلا:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"؛ }; http local-http-server { endpoints { "/dns-query"; }; }; گزینه ها { https-port 443; پورت listen-on 443 tls local-tls http myserver {any;}; }
یکی از ویژگی‌های پیاده‌سازی DoH در BIND، امکان انتقال عملیات رمزگذاری برای TLS به سرور دیگری است که ممکن است در شرایطی که گواهی‌های TLS در سیستم دیگری ذخیره می‌شوند (مثلاً در یک زیرساخت با سرورهای وب) ضروری باشد. توسط سایر پرسنل پشتیبانی از DNS-over-HTTP رمزگذاری نشده برای ساده‌سازی اشکال‌زدایی و به‌عنوان یک لایه برای ارسال به سرور دیگری در شبکه داخلی (برای انتقال رمزگذاری به یک سرور جداگانه) اجرا می‌شود. در یک سرور راه دور، nginx می تواند برای تولید ترافیک TLS، مشابه نحوه سازماندهی اتصال HTTPS برای وب سایت ها استفاده شود.
یکی دیگر از ویژگی های ادغام DoH به عنوان یک انتقال عمومی است که می تواند نه تنها برای رسیدگی به درخواست های مشتری به حل کننده، بلکه هنگام برقراری ارتباط بین سرورها، هنگام انتقال مناطق توسط یک سرور DNS معتبر، و هنگام پردازش هرگونه درخواست پشتیبانی شده توسط DNS دیگر مورد استفاده قرار گیرد. حمل و نقل می کند.
در میان کاستی هایی که می توان با غیرفعال کردن ساخت با DoH/DoT یا انتقال رمزگذاری به سرور دیگر جبران کرد، پیچیدگی کلی پایه کد برجسته است - یک سرور HTTP داخلی و کتابخانه TLS اضافه شده است که به طور بالقوه می تواند حاوی آسیب پذیری باشد. و به عنوان بردارهای حمله اضافی عمل می کنند. همچنین، هنگام استفاده از DoH، ترافیک افزایش می یابد.
به یاد بیاوریم که DNS-over-HTTPS می تواند برای جلوگیری از درز اطلاعات در مورد نام میزبان درخواستی از طریق سرورهای DNS ارائه دهندگان، مبارزه با حملات MITM و جعل ترافیک DNS (به عنوان مثال، هنگام اتصال به Wi-Fi عمومی)، مقابله مفید باشد. مسدود کردن در سطح DNS (DNS-over-HTTPS نمی تواند جایگزین VPN در دور زدن مسدودسازی اجرا شده در سطح DPI شود) یا برای سازماندهی کار در زمانی که دسترسی مستقیم به سرورهای DNS غیرممکن است (مثلاً هنگام کار از طریق یک پروکسی). اگر در شرایط عادی درخواست‌های DNS مستقیماً به سرورهای DNS تعریف‌شده در پیکربندی سیستم ارسال می‌شوند، در مورد DNS-over-HTTPS، درخواست تعیین آدرس IP میزبان در ترافیک HTTPS کپسوله شده و به سرور HTTP ارسال می‌شود. حل کننده درخواست ها را از طریق Web API پردازش می کند.
«DNS over TLS» با «DNS over HTTPS» در استفاده از پروتکل استاندارد DNS متفاوت است (درگاه شبکه 853 معمولاً استفاده می‌شود)، پیچیده شده در یک کانال ارتباطی رمزگذاری‌شده که با استفاده از پروتکل TLS با بررسی اعتبار میزبان از طریق گواهی‌های TLS/SSL تأیید شده است. توسط یک مرجع صدور گواهینامه استاندارد موجود DNSSEC از رمزگذاری فقط برای احراز هویت مشتری و سرور استفاده می کند، اما از ترافیک در برابر رهگیری محافظت نمی کند و محرمانه بودن درخواست ها را تضمین نمی کند.
برخی از نوآوری های دیگر:
- تنظیمات tcp-receive-buffer، tcp-send-buffer، udp-receive-buffer و udp-send-buffer برای تنظیم اندازه بافرهای مورد استفاده هنگام ارسال و دریافت درخواست از طریق TCP و UDP اضافه شده است. در سرورهای شلوغ، افزایش بافرهای ورودی به جلوگیری از رها شدن بسته ها در زمان اوج ترافیک کمک می کند و کاهش آنها به خلاص شدن از گرفتگی حافظه به دلیل درخواست های قدیمی کمک می کند.
- یک دسته گزارش جدید "rpz-passthru" اضافه شده است، که به شما امکان می دهد اقدامات ارسال RPZ (مناطق خط مشی پاسخ) را به طور جداگانه ثبت کنید.
- در بخش پاسخ-سیاست، گزینه "nsdname-wait-recurse" اضافه شده است، وقتی روی "خیر" تنظیم شود، قوانین RPZ NSDNAME فقط در صورتی اعمال می شود که سرورهای نام معتبر موجود در حافظه پنهان برای درخواست پیدا شوند، در غیر این صورت قانون RPZ NSDNAME نادیده گرفته می شود، اما اطلاعات در پس زمینه بازیابی می شود و برای درخواست های بعدی اعمال می شود.
- برای رکوردهایی با انواع HTTPS و SVCB، پردازش بخش "اضافی" اجرا شده است.
- اضافه شدن انواع قانون سیاست به روز رسانی سفارشی - krb5-subdomain-self-rhs و ms-subdomain-self-rhs، که به شما امکان می دهد به روز رسانی رکوردهای SRV و PTR را محدود کنید. بلوک‌های سیاست به‌روزرسانی همچنین توانایی تعیین محدودیت‌هایی در تعداد رکوردها، به‌صورت جداگانه برای هر نوع، اضافه می‌کنند.
- اطلاعات مربوط به پروتکل حمل و نقل (UDP، TCP، TLS، HTTPS) و پیشوندهای DNS64 به خروجی ابزار حفاری اضافه شد. برای اهداف اشکال زدایی، dig توانایی تعیین شناسه درخواست خاص را اضافه کرده است (dig +qid= ).
- پشتیبانی از کتابخانه OpenSSL 3.0 اضافه شده است.
- برای رسیدگی به مشکلات تکه تکه شدن IP هنگام پردازش پیام‌های DNS بزرگ شناسایی‌شده توسط DNS Flag Day 2020، کدی که اندازه بافر EDNS را در صورت عدم پاسخگویی به درخواست تنظیم می‌کند از حل‌کننده حذف شده است. اندازه بافر EDNS اکنون برای همه درخواست‌های خروجی روی ثابت (edns-udp-size) تنظیم شده است.
- سیستم ساخت به استفاده از ترکیبی از autoconf، automake و libtool تغییر یافته است.
- پشتیبانی از فایل های منطقه در قالب "نقشه" (نقشه با فرمت اصلی فایل) متوقف شده است. به کاربران این فرمت توصیه می شود با استفاده از ابزار named-compilezone، مناطق را به فرمت خام تبدیل کنند.
- پشتیبانی از درایورهای قدیمی‌تر DLZ (مناطق قابل بارگذاری پویا) متوقف شده است و ماژول‌های DLZ جایگزین آنها شده‌اند.
- پشتیبانی ساخت و اجرا برای پلتفرم ویندوز متوقف شده است. آخرین شاخه قابل نصب بر روی ویندوز BIND 9.16 است.
منبع: opennet.ru