مدیریت DNS دامنه؛ DNSSEC، TTL و مهاجرت امن

یک اشتباه یک‌خطی در DNS می‌تواند سایت، ایمیل و درگاه را هم‌زمان از دسترس خارج کند. خطر فقط حذف رکورد A نیست: DS قدیمی پس از تعویض DNS، CNAME اشتباه، TTL نامناسب، حساب Registrar تصاحب‌شده یا DMARC سخت‌گیرانه بدون Inventory می‌تواند برای بخشی از کاربران خطای نامرئی و طولانی بسازد.

پاسخ کوتاه: مدیریت DNS دامنه یعنی مالکیت و دسترسی Registrar را امن کنید، Zone و Dependencyها را فهرست کنید، رکوردها را با Change control تغییر دهید، Authoritative DNS پایدار و قابل‌پایش انتخاب کنید، DNSSEC را با زنجیره DS و Rollover درست اجرا کنید و برای مهاجرت/قطعی Runbook داشته باشید. Anycast، TTL پایین یا DNSSEC هرکدام فقط بخشی از مسئله را حل می‌کنند.

مرز این راهنما: مقاله در ۶ اوت ۲۰۲۶ بازبینی شده است. Syntax و Workflow دقیق به Registry، Registrar، DNS provider و TLD شما وابسته است؛ به‌ویژه برای دامنه .ir مراحل DS، Lock و تماس اضطراری را از پنل و مستندات جاری همان ارائه‌دهنده Verify کنید.

DNS در مسیر یک درخواست چه نقشی دارد؟

کاربر معمولاً از یک Resolver بازگشتی متعلق به ISP، سازمان یا سرویس عمومی می‌پرسد IP دامنه چیست. Resolver در صورت نبود Cache، از Root، TLD و Authoritative nameserver کمک می‌گیرد. Authoritative server رکورد Zone شما را پاسخ می‌دهد؛ Registrar نیز Delegation دامنه به Nameserverها و در DNSSEC رکورد DS را در Parent مدیریت می‌کند.

DNS معمولاً فقط ابتدای مسیر است. سریع‌شدن Lookup تضمین نمی‌کند TTFB، LCP یا Checkout بهتر شود؛ سهم DNS را جدا از TLS، سرور، Cache و Frontend بسنجید.

Inventory؛ پیش از تغییر بدانید چه دارید

Zone export نقطه شروع است، نه Inventory کامل. رکوردهای Registrar، Zone، SaaSها، Certificate، ایمیل و Cloud account را به Owner و سرویس کسب‌وکار وصل کنید.

• دامنه و Subdomain، نوع رکورد، مقدار و TTL؛
• Registrar، Registry/TLD، تاریخ انقضا و وضعیت Lock؛
• Authoritative provider، Nameserver، Account owner و MFA؛
• وب، API، ایمیل، درگاه، Helpdesk، Verification و سرویس ثالث؛
• رکوردهای DNSSEC: DNSKEY، RRSIG و DS در Parent؛
• رکوردهای امنیت ایمیل: SPF، DKIM و DMARC؛
• CAA، ACME challenge، Certificate owner و Renewal path؛
• Source of truth، آخرین تغییر، Reviewer و Runbook.

رکورد بدون Owner بدهی عملیاتی است

TXTهای قدیمی Verification، CNAME سرویس حذف‌شده و Subdomainهای بی‌صاحب می‌توانند ریسک Takeover یا افشای اطلاعات بسازند. حذف کور هم خطرناک است؛ ابتدا Dependency را از Config، Log، Certificate Transparency، Email header و تیم‌ها بررسی کنید، سپس Sunset با Monitoring انجام دهید.

رکوردهای اصلی DNS و خطای رایج

Apex و CNAME

در DNS استاندارد، Apex Zone هم‌زمان SOA و NS دارد و CNAME معمولی در همان Owner name با داده‌های دیگر تعارض دارد. بعضی Providerها ALIAS/ANAME یا CNAME flattening ارائه می‌کنند؛ رفتار Failover، DNSSEC، TTL و پشتیبانی Record type را در همان سرویس بررسی کنید و Syntax اختصاصی را قابل‌انتقال فرض نکنید.

امنیت Registrar؛ مهم‌تر از یک رکورد پیچیده

مهاجمی که حساب Registrar را بگیرد می‌تواند Nameserver یا مالکیت دامنه را تغییر دهد؛ DNSSEC به‌تنهایی این سطح را محافظت نمی‌کند. کنترل‌های پایه:

• حساب مالک سازمانی، نه ایمیل یا موبایل شخصی پیمانکار؛
• Passkey/FIDO2 یا MFA قوی و Recovery آزمایش‌شده؛
• Registrar/Transfer lock و در صورت ارائه Registry lock برای دامنه حیاتی؛
• Auto-renew با روش پرداخت و Contact پشتیبان؛
• حداقل دسترسی، حساب جدا برای عملیات و حذف کاربر خروجی؛
• هشدار تغییر Nameserver، DS، Contact و Transfer؛
• فهرست Domainها، تاریخ انقضا و Runbook بازیابی؛
• بررسی دوره‌ای EPP status و اطلاعات Registrant.

ICANN نیز Registrar lock و حفاظت از AuthInfo را لایه‌هایی برای کاهش بعضی سناریوهای Domain hijacking می‌داند؛ هیچ Lockی جای امنیت حساب و فرایند بازیابی را نمی‌گیرد.

Authoritative DNS را چگونه انتخاب کنیم؟

Anycast DNS چیست و چه چیزی را تضمین نمی‌کند؟

در Anycast، چند Node یک Prefix/IP را از نقاط مختلف اعلان می‌کنند و Routing اینترنت درخواست را بر اساس Topology و Policy به یک مسیر می‌فرستد. «نزدیک‌ترین» در اینجا الزاماً نزدیک‌ترین شهر یا کشور نیست؛ BGP path و Peering تعیین‌کننده‌اند. RFC 4786 ملاحظات عملیاتی Anycast را توضیح می‌دهد.

مزیت‌های بالقوه

• کاهش RTT برای بخشی از کاربران؛
• توزیع Query میان Siteهای متعدد؛
• کاهش اثر خرابی یک Node با Route withdrawal درست؛
• جذب و توزیع بهتر بعضی حملات DDoS؛
• ظرفیت جهانی با یک مجموعه Nameserver.

محدودیت‌ها

• Route ممکن است به Node دور یا مشکل‌دار برسد؛
• اختلال Peering می‌تواند فقط یک ISP/منطقه را درگیر کند؛
• Anycast اشتباه Zone یا خرابی Control plane را حل نمی‌کند؛
• DDoS بزرگ‌تر از ظرفیت یا حمله به Registrar همچنان اثر دارد؛
• هیچ معماری آپتایم «نزدیک ۱۰۰٪» را بدون Evidence تضمین نمی‌کند.

برای سایت ایرانی، PoP روی نقشه کافی نیست. Resolution time و Error rate را از شبکه‌های واقعی ایران و Resolverهای رایج بسنجید.

DNSSEC دقیقاً چه کاری می‌کند؟

DNSSEC به داده DNS امضا اضافه می‌کند تا Resolver اعتبارسنج بتواند اصالت مبدأ داده و عدم تغییر آن را بررسی کند. طبق توضیح ICANN درباره DNSSEC، داده Zone با کلید خصوصی امضا و کلید عمومی در Zone منتشر می‌شود.

DNSSEC این کارها را نمی‌کند:

• Query و Response را رمزنگاری نمی‌کند؛
• مالکیت Domain یا حساب Registrar را محافظت نمی‌کند؛
• جلوی DDoS، Phishing روی دامنه مشابه یا Malware سایت را نمی‌گیرد؛
• جای TLS/HTTPS و اعتبارسنجی Certificate را نمی‌گیرد؛
• در برابر رکوردی که مالک مجاز اما اشتباه منتشر کرده دفاع نمی‌کند.

زنجیره اعتماد DNSSEC

اگر DS در Parent با DNSKEY فعال Zone هماهنگ نباشد، Resolver اعتبارسنج پاسخ را Bogus می‌بیند و معمولاً SERVFAIL می‌دهد. ممکن است Resolver غیراعتبارسنج سایت را باز کند و همین تفاوت، عیب‌یابی را دشوار کند.

فعال‌سازی DNSSEC؛ «یک کلیک» فقط شروع است

1. بررسی کنید Registrar/TLD و DNS provider ترکیب سازگار دارند.
2. Zone را در Provider امضا و DNSKEY/DS پیشنهادی را دریافت کنید.
3. DS را با Algorithm، Digest type، Key tag و Digest دقیق در Registrar ثبت کنید.
4. از چند Resolver اعتبارسنج، Chain را Verify کنید.
5. هشدار RRSIG expiry، SERVFAIL و تغییر DS بسازید.
6. Runbook Key rollover و تعویض Provider را مستند کنید.

RFC ۶۷۸۱؛ DNSSEC Operational Practices تأکید می‌کند که شکستن Chain می‌تواند Zone را برای Clientهای اعتبارسنج نامرئی کند و Rollover باید با TTL و دوره امضا هماهنگ باشد.

مهاجرت Provider با DNSSEC

ترتیب دقیق به امکانات دو Provider بستگی دارد. اصل این است که در هیچ مرحله‌ای Parent DS به کلیدی اشاره نکند که Authoritativeهای فعال نتوانند اثباتش کنند. Multi-signer، Pre-publish، CDS/CDNSKEY یا Unsigned transition هرکدام Trade-off و پشتیبانی متفاوت دارند؛ Runbook Vendor را روی دامنه آزمایشی اجرا و Window کش را رعایت کنید. حذف یا افزودن کور DS هنگام تعویض Nameserver می‌تواند قطعی گسترده بسازد.

TTL چیست؟ «Propagation» را دقیق‌تر بفهمیم

TTL می‌گوید یک RRset چه مدت می‌تواند Cache شود. تغییر DNS به‌صورت جادویی در همه اینترنت Push نمی‌شود؛ Resolverها پاسخ قدیمی را تا پایان Cache نگه می‌دارند و سپس دوباره می‌پرسند. بعضی Resolverها TTL را Cap می‌کنند یا در خطا Stale data می‌دهند، پس زمان دقیق جهانی قابل‌تضمین نیست.

Negative caching

NXDOMAIN و نبود یک Record type هم Cache می‌شوند و زمان آن به SOA مرتبط است. اگر Subdomain جدید می‌سازید، ممکن است Resolver قبلاً «وجود ندارد» را Cache کرده باشد. فقط TTL رکورد A را دیدن کافی نیست؛ Negative TTL را نیز در برنامه Change لحاظ کنید.

Runbook تغییر A/AAAA یا Origin

1. رکورد، TTL فعلی، Clientها، CDN و Certificate را ثبت کنید.
2. حداقل یک دوره TTL پیش از تغییر، TTL را موقتاً کاهش دهید.
3. Origin جدید را با Host header، TLS، Firewall و محتوای واقعی تست کنید.
4. اگر IPv6 ارائه می‌کنید، AAAA و مسیر کامل IPv6 را مستقل Verify کنید.
5. رکورد را تغییر و پاسخ Authoritative و چند Resolver را بررسی کنید.
6. Log و Error rate هر دو Origin قدیم/جدید را در Window کش ببینید.
7. Origin قدیم را تا عبور TTL و تأیید Traffic نگه دارید.
8. پس از ثبات، TTL عادی و Inventory را به‌روزرسانی کنید.

اگر CDN جلوی Origin است، تغییر DNS، Proxy status و Cache rule را هم‌زمان و بدون Rollback دستکاری نکنید. معماری Origin/CDN در راهنمای CDN برای سایت ایرانی آمده است.

مهاجرت Authoritative DNS بدون قطعی

۱. Zone را کامل کپی و Diff کنید

Export قدیم را با Import جدید مقایسه کنید: A/AAAA، MX، TXT، CAA، SRV، Wildcard، Subdelegation و TTL. ALIAS/Flattening و Health check ممکن است قابل‌انتقال مستقیم نباشد.

۲. Provider جدید را پیش از Delegation تست کنید

مستقیماً Nameserver جدید را Query کنید و SOA serial، تمام Record typeها، DNSSEC state و پاسخ TCP/UDP را بسنجید. وب و ایمیل را از طریق پاسخ جدید Smoke test کنید.

۳. هم‌پوشانی دو Provider

Zone قدیم و جدید را در طول Migration همگام نگه دارید. اگر تغییر Business ضروری نیست، Freeze کوتاه‌مدت از Drift جلوگیری می‌کند. سپس Nameserverهای Parent را تغییر دهید و هر دو سرویس را تا پایان Cache/Delegation فعال نگه دارید.

۴. DNSSEC را جداگانه طراحی کنید

اگر Zone Signed است، روش تعویض Signer/DS پیش‌نیاز تغییر Nameserver است. بدون Runbook سازگار Vendor، «اول Nameserver را عوض کنیم بعد DS» خطرناک است.

۵. Verify و Decommission

Parent delegation، Glue، پاسخ هر NS، Resolverهای عمومی/ISP، DNSSEC validation، وب، ایمیل و Certificate renewal را بررسی کنید. فقط بعد از گذشت Window و صفرشدن Queryهای معنادار، Provider قبلی را خاموش کنید.

CAA؛ محدودکردن CA مجاز

CAA به مالک Domain اجازه می‌دهد CAهای مجاز برای صدور Certificate را مشخص کند. RFC 8659 Syntax و پردازش CAA را تعریف می‌کند.

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issuewild "letsencrypt.org"

این مقادیر فقط مثال‌اند. پیش از انتشار، CA واقعی Certificateهای معمولی و Wildcard، Provider CDN/Hosting و مسیر Disaster recovery را Inventory کنید. CAA اشتباه می‌تواند Renewal را متوقف کند؛ Monitoring انقضا همچنان لازم است. راهنمای انتخاب و تمدید گواهی SSL/TLS مکمل این بخش است.

DNS و امنیت ایمیل: SPF، DKIM و DMARC

این سه رکورد هدف متفاوت دارند:

در ۲۰۲۶، RFC 9989 مشخصات جاری DMARC را ارائه می‌کند. Rollout عملی:

1. همه Senderها، Helpdesk، CRM، Newsletter و Transactional mail را Inventory کنید.
2. SPF/DKIM و Alignment را برای هر مسیر اصلاح کنید.
3. DMARC را با Policy مشاهده‌ای و Aggregate report آغاز کنید.
4. منبع‌های ناشناس/مجاز را تفکیک و Forwarding را در تحلیل لحاظ کنید.
5. Policy را مرحله‌ای سخت کنید و Error/Delivery را پایش کنید.

TXT Verificationهای قدیمی را نیز پس از پایان نیاز با Owner و Evidence پاک کنید.

DoH و DoT با DNSSEC یکی نیستند

DNSSEC اصالت و Integrity داده Zone را تا Resolver اعتبارسنج بررسی می‌کند، اما Query را رمز نمی‌کند. DoH و DoT انتقال میان Client و Resolver را رمزنگاری و Resolver را Authenticate می‌کنند؛ Resolver انتخاب‌شده همچنان Queryها را می‌بیند. RFC 8484 DNS over HTTPS را تعریف می‌کند.

Secondary DNS و تفکیک Failure domain

چند NS در یک Control plane واحد ممکن است Nodeهای متعدد داشته باشد اما خطای پیکربندی سراسری را مشترک کند. Secondary DNS مستقل می‌تواند بعضی Failureها را جدا کند، اما Complexity هم می‌آورد:

• Zone transfer یا API sync باید امن و مانیتور شود؛
• Serial و Propagation میان Providerها باید همگام باشد؛
• Feature اختصاصی ALIAS/Geo/Health ممکن است منتقل نشود؛
• DNSSEC Multi-signer نیازمند طراحی تخصصی است؛
• Incident ownership و Source of truth باید روشن باشد.

برای سایت کوچک، یک Provider قوی و Runbook خروج ممکن است بهتر از Multi-provider بدپیاده‌شده باشد. برای سرویس حیاتی، PoC و Fault injection تصمیم را تعیین کند.

DNS Failover و Health check؛ درمان خودکار یا خودکارسازی خطا؟

Health-based DNS می‌تواند رکورد را هنگام Fail شدن Endpoint تغییر دهد، اما Cache اجازه Failover آنی نمی‌دهد. همچنین Healthy بودن یک URL ساده تضمین نمی‌کند Database، Login یا Checkout سالم است.

• Check را از چند Region/شبکه و با Quorum اجرا کنید؛
• Threshold، timeout و Recovery delay مانع Flapping شود؛
• Secondary واقعاً ظرفیت، Data و Certificate آماده داشته باشد؛
• TTL و Negative cache در RTO لحاظ شوند؛
• Failover و Failback هر دو Drill شوند؛
• Manual override و Audit وجود داشته باشد.

برای طراحی Probe و هشدار، راهنمای مانیتورینگ آپتایم را ببینید.

Change management و Infrastructure as Code

ویرایش مستقیم پنل بدون تاریخچه، DNS را به نقطه خطای انسانی تبدیل می‌کند. حتی اگر Provider Terraform/API کامل ندارد، Change record استاندارد بسازید.

API token DNS باید Scope حداقلی، Environment جدا، Rotation و Secret manager داشته باشد. برای Production، Approval دو‌نفره روی Nameserver، DS و MX منطقی است.

Monitoring؛ فقط Ping سایت کافی نیست

• Parent delegation و Glue؛
• پاسخ هر Authoritative NS روی UDP/TCP؛
• SOA serial و Drift میان Serverها؛
• رکوردهای حیاتی A/AAAA/CNAME/MX/TXT/CAA؛
• DNSSEC chain، RRSIG expiry و SERVFAIL؛
• Resolution latency و Error rate از داخل/خارج ایران؛
• Domain expiry، Registrar status و Nameserver change؛
• Certificate issuance/expiry و Email authentication report؛
• Correlation با Deploy، CDN و Incident.

Metric و Log را با سرویس مقصد Correlate کنید؛ راهنمای Observability برای طراحی SLO و کاهش نویز هشدار کاربرد دارد.

Runbook عیب‌یابی DNS

در Incident چه کنیم؟

1. Scope را مشخص و Evidence پنل، Audit، Query و Email notification را حفظ کنید.
2. Registrar و DNS account را از دستگاه امن Lock و Session/Tokenها را بررسی کنید.
3. Nameserver، DS، Zone و Contact را با Baseline مقایسه کنید.
4. تغییر برگشتی را با توجه به TTL و DNSSEC اجرا کنید؛ اقدام عجولانه می‌تواند Chain را بدتر کند.
5. وب، ایمیل، Certificate و Subdomainها را از چند شبکه Verify کنید.
6. Credentialها را با ترتیب امن Rotate و Recovery channel را بازبینی کنید.
7. پس از بازیابی، Root cause، Timeline و کنترل پیشگیرانه ثبت شود.

Zone export و اطلاعات Registrar باید در برنامه بازیابی سازمان باشد؛ راهنمای بازیابی فاجعه سایت چارچوب RTO/RPO و Drill را توضیح می‌دهد.

ملاحظات DNS برای کسب‌وکار ایرانی

دامنه ir و کانال بازیابی

شناسه مالک، ایمیل و دسترسی سامانه ثبت را سازمانی و به‌روز نگه دارید. فرایند DS، تغییر NS و بازیابی برای .ir را جدا از دامنه عمومی مستند کنید؛ فرض نکنید Workflow و Lock دقیقاً مشابه Registrar بین‌المللی است.

دسترسی به Provider خارجی

ریسک محدودیت حساب، پرداخت، Dashboard یا API را در Exit plan لحاظ کنید. Export دوره‌ای، DNS provider جایگزین، Account دوم سازمانی و مسیر Support خارج از پنل داشته باشید. استفاده از حساب ناشناس یا اطلاعات نادرست ریسک بازیابی را بیشتر می‌کند.

اندازه‌گیری داخل ایران

Latency و Availability را از چند ISP ثابت/موبایل، IPv4/IPv6 و Resolver رایج بسنجید. یک Probe خارج ایران نماینده مشتری داخل نیست و یک Resolver عمومی هم تمام مسیرها را نشان نمی‌دهد.

ایمیل و سرویس‌های SaaS

ارسال‌کننده‌های Transactional، CRM و Helpdesk ممکن است تغییر کنند یا دسترسی‌شان محدود شود. SPF/DKIM/DMARC و Route جایگزین را قبل از Incident آماده کنید و TXTهای Provider قبلی را بدون بررسی حذف نکنید.

Scorecard انتخاب DNS provider

امتیاز Marketing به‌تنهایی Evidence نیست. اگر Provider در شبکه‌های مشتری شما SERVFAIL/Timeout دارد یا خروج DNSSEC قابل‌آزمایش نیست، امتیاز کل بالا نباید Gate را پنهان کند.

برنامه ۳۰روزه مدیریت DNS

هفته اول: مالکیت و Inventory

• فهرست Domain/Zone/Owner/Expiry/Registrar؛
• Zone export و mapping سرویس؛
• MFA، Lock، Contact و Recovery؛
• علامت‌گذاری رکورد بدون Owner.

هفته دوم: Baseline و Monitoring

• Authoritative/Resolver probe داخل و خارج؛
• DNSSEC/Certificate/Expiry alert؛
• SOA/NS/DS/MX/CAA baseline؛
• Dashboard Error و Latency.

هفته سوم: امنیت و Email

• DNSSEC readiness و Runbook؛
• CAA بر اساس CA inventory؛
• SPF/DKIM/DMARC report و Sender map؛
• Token scope، Audit و Change template.

هفته چهارم: Drill

• تغییر رکورد آزمایشی با TTL و Rollback؛
• Zone import در Provider جایگزین؛
• Simulation خرابی NS/Origin؛
• بازیابی حساب و Escalation؛
• ثبت Gap، Owner و Deadline.

اشتباه‌های رایج

• «DNSSEC DNS را رمز می‌کند»: امضای داده با محرمانگی Query متفاوت است.
• «Anycast نزدیک‌ترین شهر را انتخاب می‌کند»: مسیر شبکه و Policy تعیین‌کننده‌اند.
• «TTL را الآن کم کردم، پس تغییر سریع است»: Cache قبلی با TTL قدیمی باقی می‌ماند.
• «Propagation دقیقاً ۲۴ ساعت است»: نوع Cache، Delegation و Resolver زمان را تغییر می‌دهد.
• «دو Nameserver یعنی دو Failure domain»: ممکن است هر دو یک Provider/Control plane باشند.
• «Failover DNS فوری است»: Cache، Health detection و State برنامه RTO را محدود می‌کنند.
• «CAA همیشه بهتر است»: بدون Inventory می‌تواند Renewal Certificate را بشکند.
• «DMARC را مستقیم Reject کنیم»: Sender مجاز جاافتاده ممکن است Email حیاتی را از دست بدهد.

سوالات متداول مدیریت DNS

DNSSEC چه تفاوتی با HTTPS دارد؟

DNSSEC اصالت و Integrity داده DNS را برای Resolver اعتبارسنج بررسی می‌کند؛ HTTPS ارتباط Application میان Client و Server را رمزنگاری و Authenticate می‌کند. این دو مکمل‌اند و هیچ‌کدام جای دیگری را نمی‌گیرد.

بهترین TTL برای DNS چند است؟

عدد ثابت عمومی وجود ندارد. TTL تابع نرخ تغییر، RTO، ظرفیت Authoritative و تحمل Stale data است. برای رکورد پایدار می‌تواند بلندتر باشد؛ پیش از Migration موقتاً کاهش می‌یابد و پس از ثبات باید بازنگری شود.

آیا Anycast DNS سرعت سایت را زیاد می‌کند؟

می‌تواند زمان Resolution و پایداری DNS را برای بعضی مسیرها بهتر کند، اما DNS فقط بخشی از بارگذاری است. TTFB، Frontend، Cache و Origin ممکن است Bottleneck اصلی باشند؛ نتیجه را از شبکه واقعی کاربران بسنجید.

چرا بعد از فعال‌سازی DNSSEC بعضی کاربران سایت را باز نمی‌کنند؟

یکی از علت‌های مهم، DS/DNSKEY/RRSIG ناسازگار یا منقضی است که Resolver اعتبارسنج آن را Bogus می‌بیند و SERVFAIL می‌دهد. Parent، هر Authoritative و زمان امضا را بررسی و Runbook Provider را دنبال کنید.

برای مهاجرت DNS از کجا شروع کنیم؟

Zone و Dependencyها را Inventory و Provider جدید را مستقیم تست کنید. دو Zone را همگام نگه دارید، TTL/Negative cache و Delegation را برنامه‌ریزی کنید و اگر DNSSEC فعال است، مسیر Signer/DS را پیش از تعویض Nameserver قطعی کنید.

جمع‌بندی

DNS زیرساخت هویت و دسترسی سرویس شماست. امنیت Registrar، Zone inventory، Authoritative پایدار، DNSSEC عملیاتی، TTL آگاهانه، Email authentication و Monitoring در کنار هم ریسک را کم می‌کنند. هر تغییر را با Evidence، Window کش و Rollback انجام دهید. برای ممیزی Zone، طراحی مهاجرت یا انتخاب DNS/CDN متناسب با کاربران ایران، درخواست مشاوره زیرساخت و DNS را ثبت کنید.