DNS Zone Transfer چیست؟ خطر AXFR باز و روش‌های امن‌سازی DNS Server

DNS Zone Transfer مکانیزمی برای همگام‌سازی اطلاعات یک DNS Zone میان سرورهای Authoritative است. در حالت AXFR کل محتوای Zone منتقل می‌شود و اگر سرور به‌اشتباه AXFR را برای هر درخواست‌کننده‌ای مجاز کند، ممکن است اطلاعات ارزشمندی درباره دامنه، زیر‌دامنه‌ها، سرویس‌ها و ساختار شبکه افشا شود. مهم‌ترین راهکارهای دفاعی، محدود کردن Zone Transfer به Secondary DNSهای مجاز، استفاده از ACL و TSIG، به‌روزرسانی DNS Server، مانیتورینگ درخواست‌های AXFR و غیرفعال کردن Transfer در صورت عدم نیاز است.

DNS یکی از مهم‌ترین بخش‌های زیرساخت اینترنت است. هر بار که کاربر نام دامنه‌ای را وارد می‌کند، سرویس‌های DNS به سیستم کمک می‌کنند مقصد صحیح آن دامنه را پیدا کند. اما DNS تنها برای تبدیل نام دامنه به IP استفاده نمی‌شود؛ در پشت صحنه، سرورهای DNS باید اطلاعات Zoneهای خود را نیز با یکدیگر هماهنگ نگه دارند.

یکی از مکانیزم‌هایی که برای این کار استفاده می‌شود DNS Zone Transfer است.

Zone Transfer ذاتاً یک قابلیت مخرب یا آسیب‌پذیری نیست. در معماری‌هایی که چند Authoritative DNS Server برای یک دامنه وجود دارد، انتقال Zone می‌تواند بخش کاملاً طبیعی و ضروری زیرساخت باشد.

مشکل از جایی شروع می‌شود که سرور اجازه دهد افراد یا سیستم‌هایی که نباید به اطلاعات Zone دسترسی داشته باشند، نسخه کامل آن را دریافت کنند.

در این شرایط با چیزی روبه‌رو می‌شویم که معمولاً با اصطلاح Open AXFR یا AXFR باز شناخته می‌شود.

یک AXFR باز ممکن است نام تعداد زیادی Subdomain، IP Address، Mail Server، Name Server و سرویس‌های دیگری را که در Zone ثبت شده‌اند در اختیار فرد غیرمجاز قرار دهد. چنین اطلاعاتی به‌تنهایی الزاماً به معنی نفوذ به سرور نیستند، اما می‌توانند مرحله Reconnaissance یا شناسایی اولیه را برای مهاجم بسیار ساده‌تر کنند.

در ادامه بررسی می‌کنیم DNS Zone Transfer چیست، AXFR و IXFR چه تفاوتی دارند، Open AXFR چه خطری ایجاد می‌کند، چرا برخی DNS Serverها ناخواسته اطلاعات Zone را افشا می‌کنند و چگونه می‌توان BIND، Windows DNS Server و سایر زیرساخت‌های DNS را در برابر انتقال Zone غیرمجاز امن کرد.

DNS Zone چیست؟

پیش از بررسی DNS Zone Transfer باید بدانیم Zone در DNS چه مفهومی دارد.

یک DNS Zone بخشی مدیریتی از فضای نام DNS است که اطلاعات مربوط به یک دامنه یا بخشی از آن را در خود نگه می‌دارد.

برای مثال Zone مربوط به دامنه:

example.com

ممکن است رکوردهایی مانند موارد زیر داشته باشد:

• A
• AAAA
• MX
• NS
• CNAME
• TXT
• SOA

در یک ساختار ساده ممکن است رکوردهایی مانند این وجود داشته باشند:

www.example.com

mail.example.com

api.example.com

vpn.example.com

shop.example.com

هرکدام از این نام‌ها می‌توانند به یک IP Address یا سرویس مشخص اشاره کنند.

اطلاعات Zone روی Authoritative DNS Server نگهداری می‌شوند و این سرور مسئول ارائه پاسخ معتبر درباره رکوردهای آن Zone است.

DNS Zone Transfer چیست؟

DNS Zone Transfer فرآیندی است که برای انتقال یا همگام‌سازی داده‌های یک DNS Zone میان DNS Serverها استفاده می‌شود.

فرض کنید یک سازمان برای دامنه خود دو Authoritative Name Server دارد:

ns1.example.com

و:

ns2.example.com

یکی از این سرورها ممکن است منبع اصلی اطلاعات Zone باشد و سرور دیگر برای افزونگی، دسترس‌پذیری و تحمل خطا نسخه‌ای هماهنگ از Zone داشته باشد.

وقتی رکوردی روی سرور اصلی تغییر می‌کند، Secondary DNS باید در زمان مناسب نسخه جدید اطلاعات را دریافت کند.

یکی از روش‌های انجام این کار Zone Transfer است.

استاندارد DNS دو مکانیزم مهم برای انتقال Zone تعریف می‌کند: AXFR برای انتقال کامل و IXFR برای انتقال تغییرات افزایشی. AXFR مجموعه کامل رکوردهای Zone را منتقل می‌کند، درحالی‌که IXFR برای کاهش حجم انتقال می‌تواند فقط تفاوت‌های لازم بین نسخه قبلی و جدید را ارسال کند.

AXFR چیست؟

AXFR مخفف Authoritative Zone Transfer است.

در AXFR، نسخه کامل Zone از یک DNS Server به Client مجاز انتقال داده می‌شود.

اگر یک Zone شامل صدها رکورد باشد، AXFR می‌تواند عملاً مجموعه کامل آن رکوردها را منتقل کند.

هدف اصلی AXFR این نیست که کاربران عادی اینترنت Zone یک دامنه را مشاهده کنند. این مکانیزم برای همگام‌سازی DNS Serverهایی طراحی شده که باید نسخه هماهنگی از یک Zone داشته باشند.

استاندارد AXFR همچنین تأکید می‌کند پیاده‌سازی DNS باید امکان محدودسازی AXFR به Clientهای مشخص را فراهم کند و سیاست پیش‌فرض نباید به شکلی باشد که تمام درخواست‌های AXFR بدون محدودیت پذیرفته شوند.

بنابراین وجود AXFR روی DNS Server طبیعی است؛ باز بودن AXFR برای سیستم‌های غیرمجاز مشکل امنیتی ایجاد می‌کند.

IXFR چیست؟

IXFR مخفف Incremental Zone Transfer است.

اگر AXFR را انتقال کامل نسخه Zone تصور کنیم، IXFR بیشتر شبیه انتقال Updateهای موردنیاز است.

فرض کنید Zone دارای هزار رکورد است و مدیر فقط یک IP را تغییر داده است.

در صورت استفاده از AXFR ممکن است کل مجموعه Zone دوباره منتقل شود.

اما IXFR می‌تواند فقط تغییرات لازم برای هماهنگ شدن Secondary با نسخه جدید را منتقل کند.

در درخواست IXFR، Secondary می‌تواند Serial Number نسخه فعلی خود را اعلام کند و سرور، در صورت داشتن اطلاعات لازم، تفاوت‌های میان نسخه موجود و نسخه جدید را ارسال کند. اگر انتقال Incremental امکان‌پذیر نباشد، سرور ممکن است در نهایت نسخه کامل Zone را منتقل کند.

این روش مخصوصاً در Zoneهای بزرگ می‌تواند میزان ترافیک و هزینه همگام‌سازی را کاهش دهد.

تفاوت AXFR و IXFR چیست؟

تفاوت اصلی در مقدار اطلاعات منتقل‌شده است.

از نظر امنیتی، هر دو نوع Transfer باید تنها در اختیار سیستم‌هایی قرار گیرند که واقعاً اجازه دریافت اطلاعات Zone را دارند.

Primary و Secondary DNS Server چه هستند؟

در معماری DNS سنتی معمولاً یک سرور منبع اطلاعات و یک یا چند سرور دیگر برای نگهداری نسخه هماهنگ Zone وجود دارند.

Primary DNS Server سروری است که نسخه قابل مدیریت یا منبع Zone را نگهداری می‌کند.

Secondary DNS Server نسخه‌ای از Zone را دریافت می‌کند تا در کنار Primary بتواند پاسخ Authoritative ارائه دهد.

Secondary بودن به معنی ضعیف‌تر یا غیرمعتبر بودن پاسخ DNS نیست. پس از همگام‌سازی، Secondary نیز می‌تواند Authoritative باشد.

وجود چند DNS Server باعث افزایش Availability می‌شود.

اگر یک سرور در دسترس نباشد، سرورهای دیگر همچنان می‌توانند Queryهای DNS را پاسخ دهند.

Zone Transfer یکی از مکانیزم‌هایی است که برای هماهنگ نگه داشتن این سرورها استفاده می‌شود.

SOA Record چه نقشی در Zone Transfer دارد؟

SOA مخفف Start of Authority است و یکی از مهم‌ترین رکوردهای هر DNS Zone محسوب می‌شود.

SOA اطلاعاتی درباره Zone و نحوه مدیریت آن در اختیار DNS Serverها قرار می‌دهد.

یکی از بخش‌های مهم SOA مقدار Serial Number است.

Serial نشان‌دهنده نسخه Zone است.

وقتی اطلاعات Zone تغییر می‌کنند، Serial نیز باید به‌روز شود.

Secondary Server می‌تواند با بررسی Serial تشخیص دهد که نسخه جدیدتری از Zone در دسترس است یا خیر.

در معماری‌های استاندارد DNS، همین مکانیزم به Secondary کمک می‌کند تصمیم بگیرد آیا لازم است اطلاعات جدیدی از Primary دریافت کند.

DNS NOTIFY چیست؟

یکی دیگر از مفاهیم مرتبط با Zone Transfer، DNS NOTIFY است.

در حالت ساده، Secondary می‌تواند در بازه‌های مشخص وضعیت Primary را بررسی کند.

اما این روش ممکن است باعث تأخیر در اعمال تغییرات شود.

NOTIFY به Primary اجازه می‌دهد پس از تغییر Zone، Secondaryهای مرتبط را از وجود نسخه جدید مطلع کند.

Secondary سپس می‌تواند فرآیند Sync را آغاز کند.

در نتیجه، AXFR، IXFR و NOTIFY در کنار یکدیگر بخشی از مکانیزم هماهنگ‌سازی Authoritative DNS Serverها را تشکیل می‌دهند. استاندارد IXFR نیز به نقش NOTIFY در کاهش تأخیر انتشار تغییرات اشاره می‌کند.

Open AXFR چیست؟

Open AXFR وضعیتی است که DNS Server بدون محدودسازی کافی، Zone Transfer کامل را در اختیار سیستم‌هایی قرار می‌دهد که نباید به آن دسترسی داشته باشند.

برای مثال فرض کنید سازمان فقط دو Secondary DNS دارد.

از نظر طراحی، Primary باید Zone Transfer را تنها برای همین Secondaryهای مشخص مجاز کند.

اگر به دلیل پیکربندی اشتباه، هر Client موجود در اینترنت بتواند درخواست AXFR ارائه کند و پاسخ کامل دریافت کند، سرور دارای تنظیم ناامن است.

این وضعیت معمولاً به عنوان DNS Zone Transfer Misconfiguration شناخته می‌شود.

خود Zone Transfer یک آسیب‌پذیری نیست؛ مشکل، کنترل دسترسی اشتباه روی آن است.

چرا AXFR باز خطرناک است؟

مهم‌ترین خطر AXFR باز Information Disclosure یا افشای اطلاعات است.

اطلاعات DNS در ظاهر ممکن است حساس به نظر نرسند، اما مجموعه کامل یک Zone می‌تواند تصویر بسیار خوبی از ساختار سرویس‌های سازمان ارائه کند.

فرض کنید Zone شامل نام‌هایی مانند موارد زیر باشد:

vpn.example.com

dev.example.com

staging.example.com

mail.example.com

jenkins.example.com

git.example.com

db-backup.example.com

old-admin.example.com

api-internal.example.com

حتی اگر هیچ‌یک از این سیستم‌ها مستقیماً آسیب‌پذیر نباشند، همین نام‌ها می‌توانند درباره نوع سرویس‌ها، فناوری‌ها و ساختار شبکه اطلاعاتی در اختیار مهاجم قرار دهند.

مایکروسافت نیز هشدار می‌دهد که اجازه Zone Transfer به هر سرور می‌تواند اطلاعاتی مانند Domain Name، Computer Name و IP سیستم‌های حساس را افشا کند و فرآیند Footprinting شبکه را برای مهاجم آسان‌تر سازد.

AXFR باز چه اطلاعاتی می‌تواند افشا کند؟

نوع اطلاعات به رکوردهایی بستگی دارد که واقعاً داخل Zone وجود دارند.

Subdomainها

یکی از مهم‌ترین نتایج افشای Zone، مشاهده نام Subdomainها است.

سرویس‌هایی که در صفحات عمومی سایت لینک نشده‌اند ممکن است همچنان رکورد DNS داشته باشند.

برای مثال:

beta.example.com

panel.example.com

monitor.example.com

یا:

legacy.example.com

مشاهده این نام‌ها می‌تواند سطح شناسایی مهاجم را افزایش دهد.

IP Addressها

A Record و AAAA Record می‌توانند مقصد سرویس‌ها را مشخص کنند.

در برخی معماری‌ها این مسئله ممکن است IPهای عمومی زیرساخت را آشکار کند.

اگر طراحی DNS داخلی نیز نامناسب باشد، حتی ممکن است اطلاعاتی درباره سیستم‌های Internal وارد Zone نامناسب شده باشند.

Mail Serverها

MX Recordها اطلاعات مربوط به مسیر دریافت ایمیل دامنه را نشان می‌دهند.

البته MXهای عمومی معمولاً ذاتاً اطلاعات سری نیستند؛ زیرا DNS عمومی برای انتشار چنین اطلاعاتی طراحی شده است.

خطر زمانی افزایش پیدا می‌کند که Zone مجموعه‌ای گسترده از نام‌های غیرضروری و اطلاعات عملیاتی را یکجا افشا کند.

Name Serverها

NS Recordها مشخص می‌کنند چه Name Serverهایی برای Zone مسئول هستند.

این اطلاعات در بسیاری موارد عمومی‌اند، اما در کنار سایر رکوردها می‌توانند دید کامل‌تری از معماری DNS ایجاد کنند.

سرویس‌های توسعه و آزمایشی

یکی از خطرناک‌ترین موارد، نام‌هایی هستند که مربوط به محیط Production نیستند.

مانند:

dev

test

staging

qa

old

backup

محیط‌های آزمایشی گاهی نسبت به Production کنترل‌های امنیتی ضعیف‌تری دارند.

به همین دلیل افشای وجود چنین سیستم‌هایی می‌تواند ارزش اطلاعاتی زیادی داشته باشد.

آیا Open AXFR به معنی هک شدن DNS Server است؟

خیر.

این نکته بسیار مهم است.

اگر یک DNS Server اجازه Zone Transfer غیرمجاز بدهد، به این معنی نیست که مهاجم کنترل سرور را در اختیار گرفته است.

AXFR باز معمولاً نوعی Security Misconfiguration و Information Disclosure محسوب می‌شود.

ممکن است مهاجم بتواند اطلاعات زیادی دریافت کند، اما این اتفاق به‌تنهایی به معنی اجرای کد، تغییر رکوردها یا نفوذ کامل نیست.

بااین‌حال اطلاعات افشاشده می‌توانند مراحل بعدی یک حمله را ساده‌تر کنند.

AXFR باز چگونه به Reconnaissance کمک می‌کند؟

Reconnaissance یا شناسایی یکی از مراحل مهم حملات سایبری است.

مهاجم قبل از تلاش برای نفوذ معمولاً سعی می‌کند بفهمد:

چه سرویس‌هایی وجود دارند؟

چه Subdomainهایی فعال هستند؟

چه سیستم‌هایی ممکن است اهمیت بیشتری داشته باشند؟

زیرساخت چگونه تقسیم شده است؟

آیا محیط Dev یا Staging وجود دارد؟

آیا سرویس قدیمی هنوز DNS Record دارد؟

AXFR باز می‌تواند بخشی از این اطلاعات را یکجا در اختیار فرد غیرمجاز قرار دهد.

بدون چنین افشایی، مهاجم ممکن است مجبور باشد Subdomainها و سرویس‌ها را با روش‌های پراکنده‌تر شناسایی کند.

بنابراین بستن AXFR غیرضروری اصل حمله را به‌طور کامل از بین نمی‌برد، اما می‌تواند مقدار اطلاعاتی را که زیرساخت مستقیماً در اختیار مهاجم قرار می‌دهد کاهش دهد.

آیا تمام رکوردهای DNS باید مخفی باشند؟

خیر.

DNS اساساً یک سیستم توزیع اطلاعات است و بسیاری از رکوردهای DNS باید عمومی باشند.

برای مثال اگر وب‌سایت عمومی دارید، اطلاعاتی باید وجود داشته باشد تا کاربران بتوانند مقصد آن را پیدا کنند.

MX نیز برای دریافت ایمیل استفاده می‌شود.

Name Serverهای Authoritative نیز باید قابل شناسایی باشند.

بنابراین هدف امنیت DNS مخفی کردن همه چیز نیست.

هدف این است که فقط اطلاعات لازم منتشر شوند و مکانیزم‌های مدیریتی مانند Zone Transfer در اختیار طرف‌های مجاز قرار داشته باشند.

این تفاوت بسیار مهم است.

خطر AXFR باز در DNS داخلی

ریسک Open AXFR در شبکه داخلی ممکن است حتی بیشتر باشد.

Internal DNS معمولاً نام‌هایی را در خود نگه می‌دارد که هرگز نباید مستقیماً از اینترنت قابل مشاهده باشند.

برای مثال:

db01.internal.example.com

backup01.internal.example.com

dc01.example.com

erp-internal.example.com

monitoring.example.com

fileserver.example.com

در صورت دسترسی یک سیستم آلوده یا مهاجم داخلی به Zone Transfer گسترده، نقشه بسیار دقیقی از زیرساخت سازمان می‌تواند ایجاد شود.

بنابراین Zone Transfer در DNS داخلی نیز باید بر اساس Least Privilege محدود شود.

Split DNS چگونه به کاهش افشای اطلاعات کمک می‌کند؟

در معماری Split DNS یا Split-Horizon DNS، اطلاعات قابل مشاهده برای کاربران داخلی و خارجی می‌تواند از یکدیگر جدا باشد.

برای مثال DNS عمومی تنها رکوردهای لازم برای کاربران اینترنت را نگه می‌دارد.

در مقابل DNS داخلی شامل رکوردهای مربوط به سرویس‌های سازمانی است.

این جداسازی باعث می‌شود نام سیستم‌های داخلی بی‌دلیل وارد Public DNS نشوند.

البته Split DNS به‌تنهایی مشکل Open AXFR را حل نمی‌کند.

اگر Internal DNS Zone Transfer برای سیستم‌های غیرمجاز باز باشد، همچنان امکان افشای اطلاعات وجود دارد.

بنابراین Separation و Access Control باید هم‌زمان استفاده شوند.

چگونه بفهمیم Zone Transfer واقعاً موردنیاز است؟

پیش از امن‌سازی AXFR یک سؤال ساده مطرح کنید:

آیا این DNS Server اصلاً به Zone Transfer نیاز دارد؟

اگر از یک DNS Provider مدیریت‌شده استفاده می‌کنید و همه Authoritative Serverها توسط همان Provider مدیریت می‌شوند، ممکن است هیچ نیازی به فعال کردن Zone Transfer برای Clientهای خارجی نداشته باشید.

در مقابل اگر خودتان Primary و Secondary DNS Serverهای مستقل دارید، Transfer ممکن است ضروری باشد.

قاعده مناسب این است:

اگر Transfer لازم نیست، آن را غیرفعال کنید.

اگر لازم است، فقط برای Secondaryهای مجاز فعال کنید.

این همان اصل Least Privilege است.

مهم‌ترین روش‌های جلوگیری از AXFR باز

امن‌سازی Zone Transfer باید چندلایه باشد.

Zone Transfer را در صورت عدم نیاز غیرفعال کنید

ساده‌ترین و مؤثرترین کنترل این است که قابلیت غیرضروری فعال نباشد.

اگر سرور هیچ Secondary مستقلی ندارد که به AXFR یا IXFR نیاز داشته باشد، باز گذاشتن Transfer هیچ مزیت عملیاتی ایجاد نمی‌کند.

هر قابلیت غیرضروری می‌تواند سطح حمله را افزایش دهد.

انتقال Zone را فقط برای Secondaryهای مشخص مجاز کنید

اگر Transfer ضروری است، Primary باید دقیقاً بداند چه سرورهایی اجازه دریافت Zone را دارند.

در بسیاری از DNS Serverها می‌توان IP Addressهای Secondaryهای مورد اعتماد را تعریف کرد.

استاندارد AXFR نیز توصیه می‌کند پیاده‌سازی‌ها امکان محدودسازی Transfer بر اساس Client را داشته باشند.

در Windows DNS نیز امکان انتخاب انتقال فقط به Name Serverهای مشخص یا IPهای تعیین‌شده وجود دارد و مایکروسافت برای امنیت بالاتر محدودسازی به IPهای مشخص را توصیه می‌کند.

از ACL استفاده کنید

ACL یا Access Control List می‌تواند تعیین کند چه Clientهایی مجاز به درخواست Zone Transfer هستند.

برای مثال در BIND گزینه allow-transfer دقیقاً برای مشخص کردن Hostهایی طراحی شده که اجازه دریافت اطلاعات Zone را دارند. تنظیم Zone می‌تواند Policy عمومی‌تر Server یا View را نیز Override کند.

بهتر است ACL تا حد ممکن محدود باشد.

اجازه دادن به Rangeهای بزرگ شبکه بدون نیاز واقعی می‌تواند سطح دسترسی را بی‌دلیل افزایش دهد.

استفاده از TSIG برای Zone Transfer

محدود کردن Transfer بر اساس IP مفید است، اما در زیرساخت‌های حساس می‌توان لایه قوی‌تری اضافه کرد.

TSIG یا Transaction Signature مکانیزمی برای احراز هویت و بررسی Integrity تراکنش‌های DNS با استفاده از Secret مشترک است.

TSIG می‌تواند برای اعتبارسنجی ارتباط میان Primary و Secondary هنگام Zone Transfer استفاده شود.

در نتیجه Primary علاوه بر IP می‌تواند بررسی کند Client دارای Credential مورد اعتماد است یا خیر.

TSIG از MAC مبتنی بر کلید مشترک برای احراز هویت تراکنش‌های DNS استفاده می‌کند و استاندارد آن صراحتاً Zone Transfer را یکی از موارد استفاده معرفی می‌کند.

نکته بسیار مهم این است که Secret مربوط به TSIG باید مانند سایر کلیدهای حساس محافظت شود.

اگر کلید در اختیار فرد غیرمجاز قرار گیرد، بخشی از مدل اعتماد از بین می‌رود.

آیا TSIG محتوای Zone Transfer را رمزنگاری می‌کند؟

خیر.

TSIG را نباید با Encryption اشتباه گرفت.

TSIG عمدتاً برای Authentication و Integrity طراحی شده است.

یعنی کمک می‌کند دو طرف بتوانند اعتبار تراکنش و دست‌کاری نشدن پیام را بررسی کنند.

اما TSIG ذاتاً Confidentiality کامل برای محتوای انتقال ایجاد نمی‌کند.

در Zone Transferهای سنتی، داده می‌تواند روی مسیر شبکه به شکل قابل مشاهده منتقل شود. استاندارد XFR-over-TLS دقیقاً برای اضافه کردن محرمانگی Channel به Zone Transfer تعریف شده است.

XFR over TLS چیست؟

XFR over TLS یا XoT روشی برای انجام Zone Transfer روی ارتباط TLS است.

هدف آن اضافه کردن Confidentiality به مسیر انتقال Zone است.

این موضوع زمانی اهمیت بیشتری پیدا می‌کند که Primary و Secondary از طریق شبکه‌ای منتقل کنند که نمی‌توان آن را کاملاً مورد اعتماد دانست.

TSIG می‌تواند Authentication و Integrity را فراهم کند.

TLS می‌تواند ارتباط را در برابر Passive Monitoring رمزنگاری کند.

در معماری مناسب، این دو کنترل می‌توانند نقش‌های مکمل داشته باشند.

آیا DNSSEC جایگزین TSIG است؟

خیر.

DNSSEC و TSIG کاربرد یکسانی ندارند.

DNSSEC برای اعتبارسنجی داده DNS و ایجاد Chain of Trust برای پاسخ‌های DNS طراحی شده است.

TSIG برای احراز هویت تراکنش میان طرف‌هایی است که Secret مشترک دارند.

برای مثال Primary و Secondary می‌توانند از TSIG برای تأیید Zone Transfer استفاده کنند.

استاندارد TSIG نیز توضیح می‌دهد این مکانیزم می‌تواند Zone Transfer را محافظت کند و نباید آن را با اعتبارسنجی مبدأ داده توسط DNSSEC یکسان دانست.

پس فعال کردن DNSSEC به این معنی نیست که دیگر نیازی به محدودسازی AXFR ندارید.

امن‌سازی Zone Transfer در BIND

BIND یکی از شناخته‌شده‌ترین DNS Serverها است.

در BIND می‌توان از allow-transfer برای مشخص کردن Clientهای مجاز استفاده کرد.

یک پیکربندی دفاعی ساده از نظر مفهومی می‌تواند شبیه ساختار زیر باشد:

acl trusted_secondaries {
    192.0.2.53;
    198.51.100.53;
};

zone "example.com" {
    type primary;
    file "example.com.zone";

    allow-transfer {
        trusted_secondaries;
    };
};

در این ساختار تنها IPهایی که داخل ACL قرار دارند اجازه Zone Transfer خواهند داشت.

آدرس‌های مثال بالا از Rangeهای مستندسازی هستند و باید در محیط واقعی با آدرس Secondaryهای مجاز جایگزین شوند.

مستندات BIND گزینه allow-transfer را برای تعریف Hostهایی ارائه می‌کند که اجازه دریافت Zone Information را دارند.

در محیط‌های حساس بهتر است این کنترل با TSIG ترکیب شود.

نمونه مفهومی محدودسازی BIND با TSIG

پیکربندی واقعی TSIG به معماری DNS و نحوه مدیریت کلیدها بستگی دارد، اما منطق امنیتی به شکل زیر است:

key "secondary-xfr-key" {
    algorithm hmac-sha256;
    secret "<protected-shared-secret>";
};

zone "example.com" {
    type primary;
    file "example.com.zone";

    allow-transfer {
        key "secondary-xfr-key";
    };
};

Secret واقعی نباید داخل Repository عمومی، Ticket، پیام‌رسان یا فایل Backup ناامن نگهداری شود.

در محیط Production بهتر است Permissions فایل حاوی کلید نیز محدود باشد.

HMAC-SHA256 یکی از الگوریتم‌های توصیه‌شده در استاندارد فعلی TSIG است.

آیا فقط محدودسازی بر اساس IP کافی است؟

برای بسیاری از محیط‌ها IP ACL یک لایه مهم دفاعی است، اما در زیرساخت حساس بهتر است تنها کنترل موجود نباشد.

دلیل آن این است که مدل امنیتی قوی‌تر باید بتواند هویت طرف مقابل را نیز تأیید کند.

ترکیب کنترل‌ها می‌تواند شامل موارد زیر باشد:

IP ACL

TSIG

Firewall

Network Segmentation

VPN

یا XFR over TLS

استاندارد AXFR نیز استفاده از Access Control و مکانیزم‌هایی مانند TSIG و ارتباطات محافظت‌شده را برای جلوگیری از Transfer غیرمجاز مطرح می‌کند.

امن‌سازی DNS Zone Transfer در Windows Server

در Windows DNS Server مدیر می‌تواند مشخص کند آیا Zone Transfer فعال باشد و چه سرورهایی اجازه دریافت Zone را داشته باشند.

در رابط مدیریتی DNS، برای Zone مربوطه می‌توان تنظیمات Zone Transfers را بررسی کرد.

به‌طور کلی سه حالت رایج وجود دارد:

انتقال برای هر Server

انتقال فقط برای سرورهایی که در Name Servers مشخص شده‌اند

انتقال فقط برای Serverهای تعیین‌شده

برای محیط حساس، حالت سوم امکان کنترل دقیق‌تری ایجاد می‌کند.

مایکروسافت توصیه می‌کند برای امنیت بالاتر Zone Transfer تنها به IP Addressهای مشخص مجاز محدود شود.

اگر Zone Transfer نیازی ندارد، گزینه مربوط به Allow Zone Transfers باید غیرفعال باشد.

نقش Firewall در محافظت از Zone Transfer

حتی اگر DNS Server دارای ACL صحیح باشد، Firewall می‌تواند لایه دفاعی دیگری ایجاد کند.

Primary DNS Server معمولاً نباید درخواست‌های Zone Transfer را از هر نقطه شبکه دریافت کند.

Firewall می‌تواند ارتباط میان Primary و Secondaryهای مورد اعتماد را محدود کند.

این مدل باعث می‌شود اگر در آینده پیکربندی DNS به اشتباه تغییر کرد، همچنان یک محدودیت شبکه‌ای وجود داشته باشد.

اصل Defense in Depth دقیقاً بر همین موضوع تأکید دارد:

امنیت نباید تنها به یک تنظیم وابسته باشد.

Zone Transfer و TCP

Zone Transferهای AXFR به‌صورت سنتی به ارتباطی نیاز دارند که بتواند جریان کامل داده را منتقل کند و AXFR در عمل از TCP استفاده می‌کند. پیاده‌سازی‌های امروزی همچنین می‌توانند Transfer را از طریق TLS انجام دهند؛ مستندات BIND فعلی انتقال Zone را روی Transportهای TCP و TLS پشتیبانی می‌کند.

این موضوع برای Firewall Ruleها اهمیت دارد.

مدیر نباید تصور کند صرفاً کنترل Queryهای معمول UDP برای امن‌سازی DNS کافی است.

سیاست Network باید متناسب با نقش واقعی DNS Server طراحی شود.

از قرار دادن اطلاعات غیرضروری در Public DNS خودداری کنید

حتی اگر AXFR کاملاً بسته باشد، هر رکوردی که در Public DNS قرار گرفته باشد ممکن است از روش‌های مختلف قابل کشف باشد.

بنابراین یکی از اصول مهم این است که اطلاعات Internal بی‌دلیل در Public DNS قرار نگیرند.

برای مثال نام‌هایی مانند:

internal-db

backup-server

dev-admin

یا اطلاعات توصیفی بسیار دقیق درباره وظیفه سرورها، در صورت عدم نیاز عملیاتی نباید در Zone عمومی قرار گیرند.

امنیت خوب تنها به پنهان کردن اطلاعات متکی نیست، اما کاهش Metadata غیرضروری می‌تواند فرآیند شناسایی مهاجم را دشوارتر کند.

نام‌گذاری DNS چه تأثیری بر امنیت دارد؟

گاهی نام Hostها اطلاعات بیشتری از چیزی که مدیر انتظار دارد فاش می‌کنند.

برای مثال:

sql-prod-primary

finance-db

vpn-admin

backup-old

نام‌ها می‌توانند درباره نقش سیستم سرنخ بدهند.

قرار نیست تمام Hostها با نام‌های تصادفی و غیرقابل مدیریت ساخته شوند، اما بهتر است Name Convention سازمانی تعادلی میان مدیریت‌پذیری و افشای اطلاعات ایجاد کند.

این موضوع مخصوصاً در Zoneهای قابل دسترسی از اینترنت اهمیت دارد.

مانیتورینگ درخواست‌های AXFR

یکی از بخش‌های مهم امنیت DNS، Logging است.

اگر DNS Server درخواست AXFR از Client غیرمنتظره دریافت کند، این رویداد می‌تواند ارزش بررسی داشته باشد.

در محیط سازمانی بهتر است درخواست‌های Zone Transfer در Logها قابل مشاهده باشند.

مواردی که باید بررسی شوند عبارت‌اند از:

افزایش ناگهانی AXFR Request

درخواست از IPهای ناشناس

درخواست‌های مکرر ردشده

Transfer در زمان غیرمعمول

تغییر Client مجاز

تغییر ACL

تغییر Zone Transfer Policy

اگر سازمان SIEM دارد، Logهای DNS می‌توانند به SIEM ارسال شوند تا Alert ایجاد شود.

آیا درخواست AXFR همیشه مخرب است؟

خیر.

Secondary DNS Server واقعی ممکن است به‌صورت کاملاً قانونی AXFR انجام دهد.

Monitoring نباید هر AXFR را حمله تلقی کند.

Context اهمیت دارد.

اگر درخواست از Secondary مورد اعتماد و در زمان معمول Sync انجام شده باشد، احتمالاً رفتار طبیعی است.

اما درخواست از IP خارجی ناشناس به Zoneای که نباید عمومی Transfer شود، نیازمند بررسی است.

Security Monitoring باید میان رفتار مجاز و رفتار غیرمنتظره تفاوت قائل شود.

چگونه AXFR باز را در تست امنیت بررسی کنیم؟

بررسی Zone Transfer می‌تواند بخشی از DNS Security Audit یا Penetration Test مجاز باشد.

در تست دفاعی ابتدا مشخص می‌شود:

چه Authoritative DNS Serverهایی برای دامنه وجود دارند؟

آیا هرکدام Zone Transfer را تنها به Secondaryهای مجاز محدود کرده‌اند؟

آیا Transfer غیرمجاز Reject می‌شود؟

آیا TSIG در معماری لازم استفاده شده است؟

آیا Firewall Policy با معماری مطابقت دارد؟

آیا رکوردهای Internal در Public Zone قرار گرفته‌اند؟

آیا Log درخواست‌های Transfer نگهداری می‌شود؟

این بررسی باید فقط روی دامنه و زیرساختی انجام شود که مجوز ارزیابی آن وجود دارد.

هدف اصلی تست نیز نباید صرفاً دریافت داده باشد؛ بلکه باید مشخص شود کنترل دسترسی Zone Transfer درست کار می‌کند یا خیر.

اگر AXFR باز پیدا کردیم چه کار کنیم؟

اگر مشخص شد DNS Server به Clientهای غیرمجاز اجازه انتقال Zone می‌دهد، اولین مرحله بررسی نیاز عملیاتی است.

اگر Transfer اصلاً لازم نیست، آن را غیرفعال کنید.

اگر لازم است، لیست Secondaryهای مجاز را مشخص کنید.

سپس Access Control ایجاد کنید.

در محیط حساس TSIG را فعال کنید.

Firewall Ruleها را بررسی کنید.

Logهای قبلی را بررسی کنید تا مشخص شود آیا IPهای ناشناسی قبلاً Transfer انجام داده‌اند.

رکوردهای Zone را نیز بازبینی کنید.

اگر اطلاعات Internal یا قدیمی داخل Zone عمومی وجود دارد، آن‌ها را در صورت عدم نیاز حذف یا به DNS داخلی منتقل کنید.

در پایان دوباره از یک نقطه غیرمجاز بررسی کنید که Transfer دیگر قابل انجام نیست.

آیا پس از بستن AXFR باید فرض کنیم اطلاعات قبلاً افشا نشده‌اند؟

خیر.

اگر سرور برای مدت نامشخصی Open AXFR داشته است، نمی‌توان با قطعیت گفت هیچ شخصی قبلاً اطلاعات Zone را دریافت نکرده است.

به همین دلیل Incident Review می‌تواند مفید باشد.

Logهای DNS و Firewall را بررسی کنید.

دنبال Connectionها یا AXFR Requestهای غیرمعمول بگردید.

همچنین اطلاعات افشاشده را از دید Risk ارزیابی کنید.

اگر Zone فقط چند رکورد عمومی داشته، تأثیر ممکن است محدود باشد.

اما اگر اطلاعات Internal، Hostهای مدیریتی یا Subdomainهای حساس وجود داشته‌اند، بررسی بیشتری لازم است.

اشتباهات رایج در تنظیم DNS Zone Transfer

فعال کردن Transfer برای Any Server

یکی از واضح‌ترین خطاها اجازه انتقال Zone به هر سرور است.

اگر تنها چند Secondary مشخص دارید، هیچ دلیلی وجود ندارد که کل اینترنت بتواند AXFR انجام دهد.

اعتماد کامل به NS Record

محدود کردن Transfer به Name Serverهای Zone بهتر از Allow Any است، اما در برخی محیط‌ها تعریف IPهای دقیق Secondaryها کنترل واضح‌تری ایجاد می‌کند.

مایکروسافت نیز محدودسازی به IP Addressهای مشخص را به‌عنوان سطح امنیتی بالاتر مطرح می‌کند.

استفاده از ACL بسیار گسترده

برای مثال مجاز کردن یک Subnet بزرگ زمانی که فقط یک Secondary به Transfer نیاز دارد، اصل Least Privilege را نقض می‌کند.

ACL باید تا حد امکان دقیق باشد.

فعال کردن قابلیت بدون مانیتورینگ

حتی پیکربندی درست نیز ممکن است در آینده تغییر کند.

Logging و Alerting کمک می‌کنند تغییرات ناخواسته زودتر شناسایی شوند.

تصور اینکه DNSSEC مشکل AXFR را حل می‌کند

DNSSEC برای اعتبارسنجی داده DNS طراحی شده و جایگزین Access Control مربوط به Zone Transfer نیست.

AXFR همچنان باید محدود شود.

ذخیره TSIG Secret در محل ناامن

اگر Secret در Repository عمومی، Configuration Backup بدون رمزگذاری یا سیستم‌های غیرمجاز ذخیره شود، امنیت TSIG کاهش پیدا می‌کند.

فراموش کردن Secondaryهای قدیمی

گاهی سازمان DNS Provider یا Secondary خود را تغییر می‌دهد، اما IPهای Provider قبلی همچنان داخل ACL باقی می‌مانند.

Access List باید به‌طور دوره‌ای Audit شود.

تفاوت Open AXFR با DNS Cache Poisoning

این دو مشکل کاملاً متفاوت‌اند.

در DNS Cache Poisoning هدف این است که اطلاعات جعلی وارد Cache یک Resolver شوند و کاربر پاسخ DNS نادرست دریافت کند.

اما در Open AXFR مهاجم یا کاربر غیرمجاز تلاش می‌کند نسخه‌ای از اطلاعات Zone واقعی را دریافت کند.

بنابراین:

DNS Cache Poisoning با Integrity پاسخ DNS ارتباط دارد.

Open AXFR بیشتر با Confidentiality و Information Disclosure مرتبط است.

در AXFR باز رکوردها الزاماً جعلی یا تغییر داده نمی‌شوند.

مشکل این است که داده واقعی در اختیار کسی قرار می‌گیرد که نباید به مجموعه کامل آن دسترسی داشته باشد.

تفاوت Zone Transfer با DNS Enumeration

DNS Enumeration اصطلاحی گسترده‌تر برای جمع‌آوری اطلاعات درباره DNS یک هدف است.

Zone Transfer می‌تواند یکی از منابع اطلاعاتی برای Enumeration باشد، اما تنها روش آن نیست.

حتی با AXFR بسته نیز ممکن است برخی Subdomainها از منابع عمومی، Certificateها یا سرویس‌های اینترنتی دیگر قابل شناسایی باشند.

بنابراین بستن AXFR به معنی نامرئی شدن زیرساخت نیست.

هدف این است که Server عمداً نسخه کامل Zone را بدون نیاز در اختیار فرد ناشناس قرار ندهد.

Zone Transfer در سرویس‌های Cloud DNS

در سرویس‌های Managed DNS ممکن است معماری با BIND سنتی متفاوت باشد.

بعضی Providerها اصلاً AXFR عمومی ارائه نمی‌کنند.

برخی قابلیت Secondary DNS دارند.

برخی از API یا مکانیزم‌های اختصاصی برای Sync استفاده می‌کنند.

بنابراین مدیر باید Documentation همان Provider را بررسی کند.

اما اصول امنیتی تغییر نمی‌کنند:

Transfer فقط در صورت نیاز فعال باشد.

طرف مقابل احراز هویت شود.

Access Control محدود باشد.

Credentialها محافظت شوند.

تغییرات مانیتور شوند.

Zone Transfer و Disaster Recovery

گاهی Zone Transfer برای Availability و Disaster Recovery اهمیت زیادی دارد.

اگر Primary DNS Server از دسترس خارج شود، Secondary می‌تواند همچنان پاسخ Authoritative ارائه دهد.

به همین دلیل راه‌حل امنیتی مناسب همیشه «خاموش کردن AXFR» نیست.

اگر معماری به آن نیاز دارد باید امن شود، نه اینکه بی‌دلیل حذف شود.

یک طراحی خوب میان Availability و Security تعادل برقرار می‌کند.

Secondaryهای مشخص، TSIG، Firewall Rule و Monitoring می‌توانند امکان استفاده ایمن از Zone Transfer را فراهم کنند.

چک‌لیست امن‌سازی DNS Zone Transfer

برای بررسی سریع DNS Server می‌توان از این چک‌لیست استفاده کرد:

• مشخص کنید هر Zone واقعاً به AXFR یا IXFR نیاز دارد یا خیر.
• Zone Transfer را برای Zoneهایی که نیاز ندارند غیرفعال کنید.
• Transfer را هرگز بدون دلیل برای Any Server باز نگذارید.
• IP Secondaryهای مجاز را به‌صورت دقیق تعریف کنید.
• از ACL محدود استفاده کنید.
• در محیط‌های حساس از TSIG برای Authentication استفاده کنید.
• Secretهای TSIG را مانند Credential حساس محافظت کنید.
• در صورت انتقال روی شبکه غیرقابل اعتماد، XFR over TLS یا تونل امن را بررسی کنید.
• Firewall را طوری تنظیم کنید که Primary و Secondary فقط در مسیرهای لازم ارتباط داشته باشند.
• DNS Server و سیستم‌عامل آن را به‌روز نگه دارید.
• Zoneهای Public و Internal را در صورت نیاز از یکدیگر جدا کنید.
• رکوردهای غیرضروری و قدیمی را حذف کنید.
• نام Hostها را از نظر افشای اطلاعات حساس بررسی کنید.
• AXFR Requestها را Logging کنید.
• درخواست‌های غیرمنتظره را Alert کنید.
• تغییر ACL و Zone Transfer Policy را مانیتور کنید.
• Secondaryهای قدیمی را از Allowlist حذف کنید.
• پس از هر تغییر، Policy را دوباره تست کنید.
• Backup امن از Configuration DNS داشته باشید.
• امنیت کنترل‌پنل DNS و حساب‌های مدیریتی را با MFA تقویت کنید.

معماری پیشنهادی برای DNS Server امن

یک معماری دفاعی مناسب می‌تواند به این شکل باشد:

Primary DNS Server مستقیماً فقط با Secondaryهای مشخص برای Transfer ارتباط داشته باشد.

Secondaryها با IP ثابت یا Identity قابل اعتماد تعریف شوند.

AXFR/IXFR با ACL محدود شود.

TSIG برای احراز هویت Transfer استفاده شود.

Firewall فقط ارتباط لازم را مجاز کند.

اگر Transfer از شبکه عمومی عبور می‌کند، Confidentiality ارتباط در طراحی در نظر گرفته شود.

Public DNS از DNS داخلی جدا باشد.

Logهای DNS به سامانه Monitoring یا SIEM ارسال شوند.

حساب‌های مدیریتی DNS با MFA محافظت شوند.

تغییرات Zone و Configuration وارد Change Management شوند.

این رویکرد باعث می‌شود شکست یک کنترل به‌تنهایی برای افشای اطلاعات Zone کافی نباشد.

نقش Least Privilege در امنیت DNS

اصل Least Privilege فقط برای User Account کاربرد ندارد.

در شبکه و DNS نیز باید اجرا شود.

اگر تنها دو Server باید Zone را دریافت کنند، فقط همان دو Server دسترسی داشته باشند.

اگر Transfer تنها بین دو Datacenter انجام می‌شود، Rule شبکه نیز بر همان اساس محدود شود.

اگر Zone خاصی به Transfer نیاز ندارد، برای آن فعال نباشد.

هر مجوز اضافه، سطح حمله را افزایش می‌دهد.

نقش Patch Management

DNS Server یک سرویس زیرساختی حیاتی است.

بنابراین Patch Management آن نباید نادیده گرفته شود.

BIND، Windows DNS و سایر پیاده‌سازی‌ها در طول زمان Updateهای امنیتی دریافت می‌کنند.

حتی اگر AXFR کاملاً محدود شده باشد، نسخه قدیمی DNS Server ممکن است آسیب‌پذیری دیگری داشته باشد.

امنیت Zone Transfer باید بخشی از Hardening کلی DNS باشد، نه تنها تنظیم یک گزینه.

چرا بررسی Configuration بعد از Migration مهم است؟

یکی از زمان‌هایی که Misconfiguration رخ می‌دهد Migration است.

برای مثال سازمان ممکن است:

DNS Provider را تغییر دهد.

Secondary جدید اضافه کند.

سرور BIND را منتقل کند.

Windows Server را Upgrade کند.

یا ساختار شبکه را عوض کند.

در این فرایند ممکن است برای رفع مشکل Sync، موقتاً Zone Transfer گسترده‌تر شود و بعد فراموش شود.

پس از Migration باید Configuration Review انجام شود.

موارد موقت باید حذف شوند.

Secondaryهای قبلی از Allowlist خارج شوند.

TSIG Keyهای غیرضروری Rotate یا حذف شوند.

Firewall نیز با معماری جدید هماهنگ شود.

امنیت Zone Transfer در محیط‌های حساس

برای زیرساخت‌هایی مانند بانک، دیتاسنتر، SaaS، سرویس‌های مالی یا سازمان‌های بزرگ بهتر است تنها به IP ACL اکتفا نشود.

ترکیب زیر می‌تواند دفاع قوی‌تری ایجاد کند:

ACL محدود

TSIG

Network Segmentation

Firewall

Logging

SIEM Alerting

XFR over TLS یا مسیر خصوصی

Configuration Management

Secret Rotation

Change Control

Periodic Security Audit

میزان کنترل لازم باید بر اساس Risk و اهمیت Zone تعیین شود.

سؤالات متداول درباره DNS Zone Transfer

DNS Zone Transfer چیست؟

DNS Zone Transfer فرآیندی برای انتقال اطلاعات DNS Zone میان سرورهای Authoritative است. این قابلیت معمولاً برای هماهنگ نگه داشتن Primary و Secondary DNS Server استفاده می‌شود.

AXFR چیست؟

AXFR مکانیزم Full Zone Transfer است و می‌تواند مجموعه کامل رکوردهای Zone را از یک DNS Server به Client مجاز منتقل کند.

IXFR چیست؟

IXFR یا Incremental Zone Transfer معمولاً فقط تغییرات لازم برای هماهنگ شدن نسخه Secondary با نسخه جدید Zone را منتقل می‌کند و نسبت به AXFR می‌تواند حجم انتقال کمتری داشته باشد.

Open AXFR چیست؟

Open AXFR وضعیتی است که DNS Server بدون محدودسازی صحیح اجازه می‌دهد Clientهای غیرمجاز Full Zone Transfer دریافت کنند.

آیا AXFR باز آسیب‌پذیری امنیتی محسوب می‌شود؟

اگر اطلاعات Zone در اختیار Clientهایی قرار گیرد که نباید به آن دسترسی داشته باشند، این وضعیت یک Security Misconfiguration و Information Disclosure مهم محسوب می‌شود.

AXFR باز چه اطلاعاتی افشا می‌کند؟

بسته به Zone ممکن است Subdomainها، IPها، Mail Serverها، Name Serverها، سرویس‌های Development، Staging یا سایر Hostnameها آشکار شوند.

آیا Open AXFR باعث هک مستقیم سرور می‌شود؟

لزوماً خیر. AXFR باز معمولاً اطلاعات را افشا می‌کند و به‌تنهایی معادل Remote Code Execution یا کنترل DNS Server نیست. بااین‌حال اطلاعات به‌دست‌آمده می‌توانند برای Reconnaissance استفاده شوند.

بهترین روش جلوگیری از AXFR باز چیست؟

اگر Zone Transfer لازم نیست، آن را غیرفعال کنید. اگر لازم است، Transfer را فقط برای Secondaryهای مشخص مجاز کرده و از ACL، Firewall و در محیط‌های حساس TSIG استفاده کنید.

TSIG چیست؟

TSIG مکانیزمی برای Authentication و Integrity تراکنش‌های DNS بر اساس Secret مشترک است و می‌تواند برای محافظت از Zone Transfer میان Primary و Secondary استفاده شود.

آیا TSIG اطلاعات AXFR را رمزنگاری می‌کند؟

خیر. TSIG Authentication و Integrity فراهم می‌کند، اما برای Confidentiality انتقال باید راهکارهایی مانند XFR over TLS یا مسیر شبکه امن در نظر گرفته شوند.

آیا DNSSEC جلوی AXFR باز را می‌گیرد؟

خیر. DNSSEC برای اعتبارسنجی داده DNS طراحی شده است و جایگزین Access Control مربوط به Zone Transfer نیست.

آیا در Windows DNS می‌توان Zone Transfer را محدود کرد؟

بله. Windows Server اجازه می‌دهد Zone Transfer غیرفعال شود یا تنها به Name Serverهای مشخص یا IP Addressهای تعیین‌شده محدود شود.

آیا BIND امکان محدود کردن AXFR دارد؟

بله. BIND گزینه allow-transfer را برای مشخص کردن Clientهای مجاز Zone Transfer ارائه می‌کند.

آیا هر سایت به Zone Transfer نیاز دارد؟

خیر. بسیاری از سایت‌هایی که از Managed DNS استفاده می‌کنند ممکن است نیازی به مدیریت مستقیم AXFR نداشته باشند. نیاز به Zone Transfer به معماری DNS بستگی دارد.

اگر AXFR باز بوده باشد، بعد از بستن آن چه کنیم؟

Logها را بررسی کنید، مشخص کنید چه مدت تنظیم ناامن بوده، محتوای Zone را از نظر اطلاعات حساس ارزیابی کنید، ACL و Firewall را اصلاح کنید و Monitoring برای درخواست‌های Transfer راه‌اندازی کنید.

جمع‌بندی

DNS Zone Transfer یکی از قابلیت‌های مهم DNS برای همگام‌سازی اطلاعات میان Authoritative DNS Serverها است و به‌خودی‌خود یک آسیب‌پذیری محسوب نمی‌شود.

AXFR نسخه کامل Zone را منتقل می‌کند، درحالی‌که IXFR می‌تواند تنها تغییرات لازم را برای هماهنگ شدن نسخه‌های DNS انتقال دهد.

مشکل امنیتی زمانی ایجاد می‌شود که یک DNS Server اجازه دهد Clientهای غیرمجاز Zone Transfer انجام دهند.

در این وضعیت Open AXFR ممکن است مجموعه بزرگی از Subdomainها، IP Addressها، Hostnameها و اطلاعات مرتبط با زیرساخت را افشا کند و مرحله Reconnaissance را برای مهاجمان ساده‌تر سازد.

اولین اصل دفاعی این است که Zone Transfer فقط زمانی فعال باشد که معماری واقعاً به آن نیاز دارد.

اگر Transfer ضروری است، دسترسی باید به Secondary DNS Serverهای مشخص محدود شود.

در BIND می‌توان از allow-transfer و ACL استفاده کرد و در Windows DNS نیز امکان محدودسازی Transfer به IP Addressهای تعیین‌شده وجود دارد. در زیرساخت‌های حساس، TSIG می‌تواند لایه Authentication و Integrity را برای تراکنش‌های DNS فراهم کند.

اگر محرمانگی محتوای انتقال نیز اهمیت دارد، TSIG به‌تنهایی کافی نیست و استفاده از مسیر خصوصی، VPN یا مکانیزم‌هایی مانند XFR over TLS می‌تواند در معماری بررسی شود.

Firewall، Network Segmentation، Split DNS، Logging، SIEM Monitoring، Patch Management و حذف اطلاعات غیرضروری از Public DNS نیز مکمل این کنترل‌ها هستند.

در نهایت، امنیت DNS Server با یک گزینه تأمین نمی‌شود. بهترین دفاع در برابر خطر AXFR باز، ترکیبی از Least Privilege، محدودسازی Zone Transfer، احراز هویت Secondaryها، مانیتورینگ مداوم و Hardening کل زیرساخت DNS است.