DNS چیست؟

وقتی آدرس یک وب‌سایت مانند example.com را در مرورگر وارد می‌کنیم، کامپیوتر باید بداند برای برقراری ارتباط با این دامنه به کدام IP Address متصل شود. کاربران معمولاً با نام‌های قابل‌خواندن مانند دامنه‌ها کار می‌کنند، اما شبکه برای برقراری ارتباط به آدرس‌های IP نیاز دارد. اینجاست که DNS یا Domain Name System وارد عمل می‌شود.

DNS را می‌توان یکی از اجزای پایه‌ای اینترنت دانست؛ سیستمی توزیع‌شده که اطلاعات مربوط به دامنه‌ها و سرویس‌های وابسته به آن‌ها را نگهداری می‌کند و امکان تبدیل نام‌های دامنه به IP Address و همچنین تعریف سرویس‌هایی مانند Mail Server را فراهم می‌کند.

در این مقاله بررسی می‌کنیم DNS چیست، DNS Resolution چگونه انجام می‌شود، Nameserver و DNS Resolver چه تفاوتی دارند، رکوردهای DNS چه کاربردی دارند، TTL و DNS Cache چگونه کار می‌کنند و چرا طراحی صحیح DNS برای Availability، Security و Performance زیرساخت اهمیت دارد.

DNS چیست؟

DNS یا Domain Name System یک سیستم سلسله‌مراتبی و توزیع‌شده برای نگاشت نام‌های دامنه به اطلاعات موردنیاز شبکه است. رایج‌ترین کاربرد DNS، تبدیل یک نام دامنه مانند example.com یا api.example.com به یک IPv4 یا IPv6 Address است.

برای مثال، کاربر به جای حفظ کردن یک IP مانند:

203.0.113.10

www.example.com

DNS فقط برای پیدا کردن IP وب‌سایت نیست. رکوردهای DNS می‌توانند مشخص کنند ایمیل یک دامنه به کدام Mail Server ارسال شود، یک نام مستعار به کدام hostname اشاره کند، چه Nameserverهایی مسئول یک Zone هستند و حتی اطلاعاتی برای سرویس‌های مختلف و مکانیزم‌های اعتبارسنجی ارائه کنند.

چرا DNS به وجود آمد؟

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

فرض کنید برای دسترسی به میلیون‌ها سرویس اینترنتی، هر کامپیوتر مجبور باشد یک فایل محلی شامل نام و IP تمام سرویس‌ها داشته باشد. هر تغییر IP نیز باید به تمام سیستم‌ها منتقل شود. چنین مدلی عملاً قابل مدیریت نیست.

DNS این مشکل را با ایجاد یک سیستم Hierarchical، Distributed و Cacheable حل کرد.

DNS چگونه کار می‌کند؟

فرآیند پیدا کردن اطلاعات یک دامنه را DNS Resolution یا DNS Lookup می‌نامیم.

فرض کنیم کاربر در مرورگر وارد آدرس زیر می‌شود:

www.example.com

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

1. Browser یا سیستم‌عامل بررسی می‌کند آیا پاسخ DNS در Cache محلی وجود دارد یا خیر.
2. در صورت نبودن پاسخ، درخواست به یک Recursive DNS Resolver ارسال می‌شود.
3. Resolver در صورت نیاز Root DNS Server را بررسی می‌کند.
4. Root Server مشخص می‌کند کدام DNS Server مسئول TLD مانند .com است.
5. Resolver از TLD Server اطلاعات مربوط به Nameserverهای دامنه را دریافت می‌کند.
6. Resolver از Authoritative Nameserver مربوط به دامنه، رکورد موردنیاز را درخواست می‌کند.
7. پاسخ به Resolver بازمی‌گردد و معمولاً برای مدت مشخصی Cache می‌شود.
8. در نهایت IP به Client بازگردانده می‌شود و مرورگر می‌تواند ارتباط HTTP/HTTPS را با مقصد برقرار کند.

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

ساختار سلسله‌مراتبی DNS

DNS یک ساختار سلسله‌مراتبی دارد. برای دامنه‌ای مانند:

api.example.com

• . → Root
• com → Top-Level Domain یا TLD
• example.com → Domain
• api.example.com → Hostname یا Subdomain

این ساختار باعث می‌شود مسئولیت مدیریت نام‌ها بین بخش‌های مختلف DNS تقسیم شود و یک سیستم مرکزی مجبور نباشد تمام اطلاعات اینترنت را نگهداری کند.

DNS Resolver چیست؟

DNS Resolver سیستمی است که درخواست DNS Client را دریافت می‌کند و در صورت نیاز مراحل لازم برای پیدا کردن پاسخ را انجام می‌دهد.

برای مثال ممکن است سیستم شما DNS Server مربوط به ISP را استفاده کند، یا DNS Resolver عمومی مانند سرویس‌های عمومی شرکت‌های مختلف را انتخاب کرده باشید.

Resolver معمولاً از Cache استفاده می‌کند. اگر پاسخ یک Query قبلاً در Cache موجود باشد و TTL آن منقضی نشده باشد، Resolver می‌تواند بدون مراجعه دوباره به Authoritative DNS، همان پاسخ را برگرداند.

Authoritative DNS Server چیست؟

Authoritative DNS Server سروری است که اطلاعات معتبر DNS مربوط به یک Zone را در اختیار دارد.

به عنوان مثال، اگر Nameserverهای دامنه example.com مسئول Zone مربوط به این دامنه باشند، رکوردهای DNS مانند A، MX، TXT و CNAME در ساختار DNS آن Zone قرار می‌گیرند.

تفاوت مهم این دو مفهوم را می‌توان این‌گونه خلاصه کرد:

Nameserver چیست؟

Nameserver یک DNS Server است که برای پاسخ‌گویی درباره یک Domain یا Zone استفاده می‌شود.

برای مثال ممکن است هنگام ثبت یک دامنه، Nameserverهایی مانند این داشته باشید:

ns1.example-dns.com
ns2.example-dns.com

قرار دادن این Nameserverها در رجیستری مربوط به دامنه، مشخص می‌کند درخواست‌های DNS مربوط به آن دامنه باید در نهایت به کدام Authoritative DNS Serverها برسند.

داشتن چند Nameserver در زیرساخت Production اهمیت زیادی دارد، زیرا در صورت از دسترس خارج شدن یکی از آن‌ها، Resolverها می‌توانند از Nameserver دیگری استفاده کنند.

DNS Record چیست؟

DNS Record یک رکورد اطلاعاتی در DNS است که مشخص می‌کند یک نام دامنه یا Hostname چه اطلاعاتی دارد یا باید به چه سرویسی اشاره کند.

هر Record معمولاً شامل اطلاعاتی مانند:

• Name
• Type
• Value / Content
• TTL

است.

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

مهم‌ترین انواع رکوردهای DNS

رکورد A

رکورد A یکی از رایج‌ترین رکوردهای DNS است و یک Hostname را به یک یا چند IPv4 Address متصل می‌کند.

example.com    A       203.0.113.10

یعنی Resolver می‌تواند برای example.com آدرس IPv4 مشخص‌شده را برگرداند.

رکورد AAAA

رکورد AAAA برای نگاشت نام دامنه به IPv6 استفاده می‌شود.

example.com    AAAA    2001:db8::10

بنابراین در زیرساخت‌هایی که IPv6 فعال است، ممکن است یک سرویس هم A Record و هم AAAA Record داشته باشد.

رکورد CNAME

CNAME برای ایجاد Alias استفاده می‌شود.

www.example.com    CNAME    example.com

در این حالت www.example.com به نام canonical دیگری اشاره می‌کند.

CNAME در معماری‌های Cloud و سرویس‌هایی که مقصد ممکن است تغییر کند کاربرد زیادی دارد.

رکورد MX

رکورد MX مشخص می‌کند ایمیل‌های مربوط به یک Domain باید به کدام Mail Server ارسال شوند.

example.com    MX    10    mail.example.com

عدد Priority مشخص می‌کند در شرایطی که چند Mail Server وجود دارد، ترتیب اولویت آن‌ها چگونه باشد.

رکورد TXT

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

از کاربردهای رایج آن می‌توان به:

• SPF
• Domain Verification
• DKIM-related DNS data
• سرویس‌های مختلف برای اثبات مالکیت Domain

اشاره کرد.

رکورد NS

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

رکورد SOA

SOA یا Start of Authority اطلاعات مدیریتی اصلی یک DNS Zone را نگهداری می‌کند و شامل فیلدهایی مانند Serial، Refresh، Retry، Expire و Minimum است.

رکورد PTR و Reverse DNS

در DNS معمولاً از نام دامنه به سمت IP حرکت می‌کنیم؛ اما در Reverse DNS مسیر برعکس است و یک IP به Hostname نگاشت می‌شود.

این کار معمولاً با PTR Record انجام می‌شود و در سرویس‌هایی مانند Mail Infrastructure اهمیت ویژه‌ای دارد.

TTL در DNS چیست؟

TTL یا Time To Live مشخص می‌کند یک DNS Record تا چه مدت می‌تواند توسط Resolverها Cache شود.

برای مثال:

example.com    300    A    203.0.113.10

در این مثال TTL برابر ۳۰۰ ثانیه است.

TTL پایین‌تر باعث می‌شود تغییرات DNS معمولاً سریع‌تر قابل مشاهده شوند، اما در مقابل تعداد Queryهای بیشتری ممکن است به سمت DNS Infrastructure ایجاد شود.

TTL بالاتر می‌تواند باعث کاهش Queryهای تکراری و استفاده بیشتر از Cache شود، اما تغییرات DNS ممکن است مدت بیشتری در Cache باقی بمانند.

DNS Cache چیست؟

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

این Cache می‌تواند در بخش‌هایی مانند:

• Browser
• Operating System
• Local Network
• Recursive DNS Resolver

وجود داشته باشد.

در نتیجه، DNS Cache نقش مهمی در کاهش Latency، کاهش ترافیک DNS و کاهش بار روی Authoritative DNS دارد.

اگر IP سرور را تغییر دهیم چه اتفاقی می‌افتد؟

یکی از اشتباهات رایج این است که تصور کنیم بعد از تغییر A Record، تمام کاربران اینترنت بلافاصله IP جدید را دریافت می‌کنند.

در واقع اگر پاسخ قبلی در Resolverهای مختلف Cache شده باشد، تا پایان TTL ممکن است همان IP قبلی ارائه شود.

به همین دلیل هنگام Migration یا تغییر زیرساخت Production معمولاً باید برنامه تغییر DNS با TTL و زمان‌بندی Migration هماهنگ شود.

DNS Propagation چیست؟

اصطلاح DNS Propagation معمولاً برای توصیف زمانی استفاده می‌شود که تغییرات DNS در Cacheهای مختلف اینترنت به تدریج جایگزین می‌شوند.

در واقع DNS یک دیتابیس مرکزی نیست که یک تغییر در آن بلافاصله در تمام نقاط اینترنت منعکس شود. Resolverهای مختلف ممکن است پاسخ قبلی را تا زمان انقضای TTL خود نگه دارند.

بنابراین هنگام تغییر DNS باید به موارد زیر توجه کرد:

• TTL فعلی Record
• Cache Resolverها
• تعداد Nameserverها
• صحت DNS Zone
• وجود A و AAAA Recordهای قدیمی
• وضعیت سرویس مقصد

DNS و Load Balancing

DNS می‌تواند در برخی معماری‌ها برای توزیع ترافیک بین چند IP نیز استفاده شود.

برای مثال ممکن است یک نام دامنه چند A Record داشته باشد:

api.example.com    A    203.0.113.10
api.example.com    A    203.0.113.20
api.example.com    A    203.0.113.30

با این حال DNS را نباید با Load Balancerهایی مانند HAProxy یا NGINX یکی دانست. DNS معمولاً در سطح Name Resolution تصمیم‌گیری می‌کند، در حالی که Load Balancer می‌تواند در مسیر واقعی ترافیک، وضعیت Backendها، Connectionها و Health Checkها را بررسی کند.

در معماری‌های حرفه‌ای، DNS و Load Balancing می‌توانند در کنار یکدیگر استفاده شوند.

DNS Failover چیست؟

در معماری‌های High Availability، DNS می‌تواند بخشی از مکانیزم Failover باشد.

برای مثال فرض کنید یک سرویس در دو Data Center قرار دارد:

DC1 → 203.0.113.10
DC2 → 198.51.100.10

یک DNS Provider می‌تواند بر اساس Health Check یا سیاست‌های تعریف‌شده، پاسخ DNS را به سمت مقصد مناسب هدایت کند.

با این حال باید توجه داشت که DNS Failover به دلیل وجود Cache و TTL، معمولاً جایگزین کامل Load Balancing یا سایر مکانیزم‌های Failover در لایه‌های پایین‌تر نیست.

برای سرویس‌های حساس، DNS باید به عنوان یکی از اجزای معماری High Availability در نظر گرفته شود، نه تنها مکانیزم HA.

DNS در معماری Multi-DC

در معماری‌های چند دیتاسنتری، DNS می‌تواند نقش مهمی در Traffic Steering داشته باشد.

بسته به DNS Provider و معماری مورد استفاده، می‌توان سیاست‌هایی مانند موارد زیر را پیاده‌سازی کرد:

• Failover بین Data Centerها
• GeoDNS
• Latency-based Routing
• Weighted Routing
• Active/Passive Architecture
• Active/Active Architecture

برای مثال، ممکن است کاربران یک منطقه به Data Center نزدیک‌تر هدایت شوند و در صورت Failure، مقصد دیگری انتخاب شود.

البته اجرای صحیح چنین معماری‌ای نیازمند بررسی Health Check، TTL، ظرفیت مقصدها، Session Management و رفتار Application است.

DNS و CDN چه ارتباطی دارند؟

DNS یکی از نقاط مهم در معماری CDN است.

در بسیاری از معماری‌ها، DNS به جای اینکه مستقیماً IP Origin Server را به کاربر بدهد، کاربر را به زیرساخت CDN یا Reverse Proxy هدایت می‌کند.

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

User
  ↓
DNS
  ↓
CDN / Edge
  ↓
Load Balancer
  ↓
Origin Server

در این معماری Origin Server می‌تواند پشت CDN قرار داشته باشد و CDN وظایفی مانند Caching، TLS Termination، DDoS Mitigation و WAF را نیز انجام دهد.

برای آشنایی بیشتر با این معماری می‌توانید مقاله CDN چیست؟ را مطالعه کنید.

DNS و امنیت

DNS از نظر امنیتی یکی از اجزای مهم Infrastructure است. اختلال یا دستکاری DNS می‌تواند باعث شود کاربران به مقصد اشتباه هدایت شوند یا یک سرویس از دسترس خارج شود.

به همین دلیل امنیت DNS باید بخشی از برنامه کلی Security Hardening باشد.

DNSSEC چیست؟

DNSSEC یا DNS Security Extensions مجموعه‌ای از مکانیزم‌های رمزنگاری برای فراهم کردن Origin Authentication در داده‌های DNS است.

هدف DNSSEC این است که Resolver بتواند بررسی کند پاسخ DNS از منبع معتبر Zone آمده و داده DNS در مسیر به شکل غیرمجاز تغییر نکرده است.

DNSSEC با HTTPS یکسان نیست. HTTPS از ارتباط HTTP محافظت می‌کند، در حالی که DNSSEC روی اعتبارسنجی داده‌های DNS تمرکز دارد.

DNS over HTTPS و DNS over TLS

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

• DNS over HTTPS یا DoH
• DNS over TLS یا DoT

این فناوری‌ها برای رمزنگاری ارتباط بین Client و DNS Resolver استفاده می‌شوند و با DNSSEC تفاوت دارند.

به صورت ساده:

DNS Hijacking چیست؟

DNS Hijacking به سناریوهایی گفته می‌شود که در آن Resolution DNS به شکل غیرمجاز تغییر داده می‌شود تا کاربر به مقصدی متفاوت از مقصد واقعی هدایت شود.

به همین دلیل کنترل صحیح دسترسی به DNS Provider، محافظت از حساب‌های مدیریتی، استفاده از MFA و در صورت نیاز استفاده از DNSSEC اهمیت دارد.

DNS و DDoS

DNS Infrastructure خودش نیز می‌تواند هدف حملات مختلف قرار گیرد. علاوه بر این، DNS در معماری دفاع از سرویس‌های Web نیز نقش دارد.

در معماری‌های مدرن، استفاده از DNS Providerهای توزیع‌شده، Anycast، CDN، DDoS Protection و چند Nameserver می‌تواند به افزایش Resilience زیرساخت کمک کند.

با این حال باید میان DDoS روی DNS Infrastructure و DDoS روی Application یا Origin تفاوت قائل شد.

برای آشنایی بیشتر با این موضوع، مقاله حملات DDoS چیست؟ را ببینید.

DNS در Kubernetes

DNS فقط در اینترنت و Domain Nameها استفاده نمی‌شود. در Kubernetes نیز DNS یکی از اجزای مهم Service Discovery است.

در یک Cluster کوبرنتیس، سرویس‌ها معمولاً می‌توانند با استفاده از نام Service به جای IP مستقیماً یکدیگر را پیدا کنند.

برای مثال:

payment-service
user-service
redis-service

این نام‌ها توسط DNS داخلی Cluster Resolution می‌شوند.

این موضوع یکی از دلایلی است که DNS در معماری Microservices اهمیت زیادی پیدا می‌کند؛ زیرا سرویس‌ها به جای وابستگی مستقیم به IPهای ثابت، از نام‌های پایدار استفاده می‌کنند.

برای آشنایی بیشتر با معماری Kubernetes می‌توانید مقاله کوبرنتیس چیست؟ را مطالعه کنید.

DNS در معماری Microservices

در معماری Microservices معمولاً تعداد سرویس‌ها زیاد است و IP یا محل اجرای آن‌ها می‌تواند تغییر کند.

به همین دلیل Service Discovery اهمیت پیدا می‌کند.

به جای اینکه Application مستقیماً به IP سرویس متصل شود:

http://10.20.30.40:8080

http://payment-service:8080

DNS و Service Discovery در اینجا نقش Abstraction Layer را ایفا می‌کنند و تغییر محل اجرای سرویس را برای مصرف‌کننده پنهان می‌کنند.

DNS و Email

DNS برای زیرساخت Email اهمیت ویژه‌ای دارد. رکوردهای MX مشخص می‌کنند ایمیل‌های یک Domain به کدام Mail Server تحویل داده شوند.

اما برای راه‌اندازی حرفه‌ای Email، فقط MX کافی نیست. رکوردهای مرتبط با Authentication مانند SPF، DKIM و DMARC نیز معمولاً در DNS تنظیم می‌شوند.

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

• دریافت نشدن ایمیل
• ارسال نشدن ایمیل
• Fail شدن Domain Verification
• مشکلات Email Authentication
• افزایش احتمال Spam شدن ایمیل‌ها

شود.

DNS و Reverse Proxy

DNS و Reverse Proxy دو مفهوم متفاوت اما مکمل هستند.

DNS مشخص می‌کند یک نام به چه مقصدی Resolution شود، در حالی که Reverse Proxy درخواست‌های واقعی Client را دریافت کرده و آن‌ها را به Backend مناسب Forward می‌کند.

برای مثال:

DNS
  ↓
203.0.113.10
  ↓
Nginx / HAProxy / Caddy
  ↓
Application Servers

برای آشنایی بیشتر با Reverse Proxy، مقاله Reverse Proxy چیست؟ را مطالعه کنید.

DNS چه تأثیری بر Performance دارد؟

DNS معمولاً بخش کوچکی از زمان برقراری ارتباط با یک سرویس را تشکیل می‌دهد، اما در سیستم‌های با تعداد زیاد Request و کاربران زیاد، طراحی مناسب DNS همچنان اهمیت دارد.

مواردی مانند:

• موقعیت جغرافیایی DNS Resolver
• Cache Hit Rate
• TTL
• Anycast
• تعداد و پراکندگی Nameserverها
• Latency شبکه

می‌توانند بر سرعت و Resilience فرآیند Resolution اثر بگذارند.

آیا DNS روی سرعت سایت تأثیر دارد؟

بله، اما باید این موضوع را دقیق بیان کرد. DNS یکی از مراحل قبل از برقراری ارتباط با Web Server است و تأخیر در Resolution می‌تواند به زمان شروع اتصال اضافه شود.

اما DNS معمولاً عامل اصلی کندی یک وب‌سایت نیست. مواردی مانند Backend Performance، Database، Network Latency، حجم فایل‌ها، CDN، تعداد درخواست‌ها و Frontend نیز می‌توانند تأثیر بسیار بیشتری داشته باشند.

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

DNS Primary و Secondary چیست؟

برای افزایش Resilience، می‌توان DNS را با معماری Primary / Secondary DNS طراحی کرد.

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

این معماری باعث می‌شود وابستگی به یک DNS Server کاهش پیدا کند و در صورت Failure یک سرویس، Nameserverهای دیگر همچنان پاسخ‌گو باشند.

چرا نباید فقط یک Nameserver داشته باشیم؟

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

حتی اگر Web Server کاملاً سالم باشد، کاربران ممکن است نتوانند Domain را به IP موردنظر Resolution کنند.

به همین دلیل در Production معمولاً از چند Nameserver و ترجیحاً زیرساخت‌های مستقل استفاده می‌شود.

در معماری‌های حساس‌تر حتی می‌توان از چند DNS Provider استفاده کرد تا Failure یک Provider کل DNS Domain را تحت تأثیر قرار ندهد.

اشتباهات رایج در مدیریت DNS

۱. تغییر DNS بدون بررسی TTL

اگر قبل از Migration، TTL مدیریت نشده باشد، تغییر مقصد ممکن است برای مدتی رفتار متفاوتی در Resolverهای مختلف داشته باشد.

۲. حذف اشتباه رکوردهای Email

گاهی هنگام تغییر DNS، رکوردهای MX، SPF، DKIM یا سایر TXT Recordها حذف می‌شوند و Email Infrastructure دچار مشکل می‌شود.

۳. فراموش کردن AAAA Record

اگر IPv6 فعال باشد اما AAAA Record به مقصد اشتباه اشاره کند، ممکن است برخی کاربران با مشکلاتی مواجه شوند؛ حتی در حالی که IPv4 کاملاً سالم است.

۴. استفاده از یک DNS Provider به عنوان Single Point of Failure

برای سرویس‌های حساس، وابستگی کامل به یک DNS Infrastructure می‌تواند ریسک Availability ایجاد کند.

۵. باز گذاشتن Recursive DNS

Recursive Resolverهای عمومی باید با دقت پیکربندی شوند. یک Resolver اشتباه پیکربندی‌شده می‌تواند در معرض سوءاستفاده قرار گیرد.

۶. نادیده گرفتن امنیت حساب DNS Provider

کنترل DNS در بسیاری از سازمان‌ها عملاً به معنی کنترل مسیر دسترسی به سرویس‌ها است. بنابراین Account Security، MFA، RBAC و Audit Logging باید جدی گرفته شوند.

چک‌لیست DNS برای محیط Production

• استفاده از حداقل دو Nameserver
• بررسی استقلال زیرساخت DNS
• مدیریت مناسب TTLها
• مانیتورینگ DNS Availability
• بررسی A و AAAA Recordها
• بررسی MX و رکوردهای مرتبط با Email
• محافظت از حساب DNS Provider با MFA
• محدود کردن دسترسی مدیریتی با RBAC
• فعال‌سازی DNSSEC در صورت پشتیبانی و مناسب بودن برای معماری
• ثبت و مستندسازی تغییرات DNS
• بررسی DNS قبل از Migration
• مانیتور کردن Resolution از چند نقطه جغرافیایی
• در نظر گرفتن DNS در طراحی High Availability
• بررسی DNS به عنوان بخشی از Disaster Recovery

DNS در Disaster Recovery

در طراحی Disaster Recovery، DNS نباید یک جزئیات فرعی در نظر گرفته شود.

ممکن است سازمان Backup، Server و Database کاملاً آماده‌ای داشته باشد، اما اگر بعد از Disaster نتواند کاربران را به زیرساخت جدید هدایت کند، فرآیند Recovery کامل نخواهد بود.

به همین دلیل در یک طراحی DR حرفه‌ای باید مواردی مانند موارد زیر از قبل مشخص شده باشند:

• DNS Provider
• Nameserverها
• TTL
• Failover Strategy
• Domain Ownership
• Access Credentials
• Recordهای ضروری
• روش تغییر مقصد سرویس‌ها

این موضوع بخشی از طراحی صحیح Disaster Recovery و Business Continuity است.

DNS Monitoring چیست؟

صرفاً داشتن DNS کافی نیست؛ باید بتوان عملکرد آن را نیز مشاهده و بررسی کرد.

در یک سیستم Production می‌توان مواردی مانند:

• DNS Response Time
• Availability
• NXDOMAIN Rate
• Resolution Errors
• Nameserver Availability
• تغییرات غیرمنتظره Recordها

را پایش کرد.

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

DNS را چگونه در یک معماری حرفه‌ای طراحی کنیم؟

برای یک سرویس ساده ممکن است یک DNS Provider و چند Record کاملاً کافی باشد. اما با افزایش اهمیت سرویس، طراحی DNS نیز باید متناسب با سطح Availability موردنیاز رشد کند.

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

                    Internet
                       │
                Recursive Resolvers
                       │
             ┌─────────┴─────────┐
             │                   │
          DNS Provider A      DNS Provider B
             │                   │
             └─────────┬─────────┘
                       │
                 CDN / Anycast
                       │
                  Load Balancer
                       │
             ┌─────────┴─────────┐
             │                   │
           DC1                   DC2
             │                   │
       Application           Application

این معماری فقط یک نمونه مفهومی است و طراحی واقعی باید بر اساس SLA، نوع Application، موقعیت کاربران، Data Centerها، روش Failover و الزامات امنیتی تعیین شود.

آیا هر وب‌سایتی به DNS پیچیده نیاز دارد؟

خیر.

پیچیده کردن DNS بدون نیاز واقعی می‌تواند مدیریت زیرساخت را دشوارتر کند.

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

A
AAAA
www CNAME
MX
TXT

اما برای یک پلتفرم Enterprise با چند Data Center، CDN، Kubernetes، Microservices، Email Infrastructure و الزامات Availability، DNS می‌تواند بخشی از معماری پیچیده‌تر باشد.

قاعده مناسب این است که DNS به اندازه‌ای پیچیده شود که نیازهای واقعی معماری را پوشش دهد؛ نه بیشتر.

DNS و خدمات دواپس

DNS در بسیاری از پروژه‌های خدمات دواپس و خدمات DevOps به صورت مستقیم یا غیرمستقیم با بخش‌های مختلف Infrastructure درگیر است.

در یک پروژه DevOps ممکن است DNS در کنار اجزایی مانند:

• CI/CD
• Kubernetes
• Load Balancer
• Reverse Proxy
• CDN
• Monitoring
• High Availability
• Disaster Recovery
• Security

طراحی و مدیریت شود.

به همین دلیل DNS را نباید صرفاً یک صفحه ساده برای وارد کردن IP در پنل Domain دانست؛ در معماری‌های بزرگ، DNS بخشی از Control Plane دسترسی کاربران به سرویس‌ها است.

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

DNS مخفف چیست؟

DNS مخفف Domain Name System است.

DNS چه کاری انجام می‌دهد؟

DNS اطلاعات موردنیاز برای پیدا کردن سرویس‌ها بر اساس نام دامنه را ارائه می‌کند و رایج‌ترین کاربرد آن تبدیل Domain Name به IP Address است.

DNS Server و DNS Resolver چه تفاوتی دارند؟

Resolver معمولاً برای Client عملیات پیدا کردن پاسخ را انجام می‌دهد، در حالی که Authoritative DNS Server اطلاعات معتبر یک Zone را در اختیار دارد.

A و AAAA چه تفاوتی دارند؟

A برای IPv4 و AAAA برای IPv6 استفاده می‌شود.

CNAME چیست؟

CNAME یک نام را به یک Canonical Hostname دیگر Alias می‌کند.

TTL در DNS یعنی چه؟

TTL مدت زمانی است که یک DNS Record می‌تواند توسط Resolverها Cache شود.

آیا DNS روی سرعت سایت تأثیر دارد؟

DNS می‌تواند روی زمان شروع برقراری ارتباط تأثیر بگذارد، اما سرعت سایت به مجموعه‌ای از عوامل مانند Application، Backend، Database، Network، CDN و Frontend وابسته است.

آیا DNSSEC همان HTTPS است؟

خیر. DNSSEC برای اعتبارسنجی داده‌های DNS طراحی شده است، در حالی که HTTPS از ارتباط HTTP بین Client و Server محافظت می‌کند.

چرا داشتن چند Nameserver مهم است؟

چند Nameserver می‌تواند وابستگی به یک DNS Server را کاهش دهد و در افزایش Resilience و Availability زیرساخت DNS مؤثر باشد.

جمع‌بندی

DNS یا Domain Name System یکی از پایه‌ای‌ترین اجزای اینترنت است و وظیفه آن بسیار فراتر از یک تبدیل ساده Domain به IP است.

DNS یک سیستم توزیع‌شده و سلسله‌مراتبی است که با استفاده از Resolverها، Authoritative Nameserverها، DNS Records و Cache امکان دسترسی به سرویس‌ها را بر اساس نام فراهم می‌کند.

درک مفاهیمی مانند A، AAAA، CNAME، MX، TXT، NS، SOA، TTL، DNS Cache، DNSSEC، Recursive Resolver و Authoritative DNS برای هر تیم زیرساخت، DevOps و SRE ضروری است.

در معماری‌های پیشرفته‌تر نیز DNS می‌تواند در CDN، Load Balancing، Multi-DC، High Availability، Disaster Recovery، Kubernetes و Service Discovery نقش داشته باشد.

در نتیجه، طراحی DNS باید متناسب با اهمیت سرویس انجام شود. برای یک وب‌سایت ساده، DNS می‌تواند بسیار ساده باشد؛ اما برای یک سامانه Enterprise، DNS باید به عنوان یکی از اجزای مهم Availability، Security و Resilience زیرساخت طراحی و مانیتور شود.

آماده‌سازی و مدیریت DNS برای زیرساخت‌های Production

اگر DNS فقط یک بخش کوچک از یک مسئله بزرگ‌تر زیرساختی است و سرویس شما به معماری‌هایی مانند High Availability، Multi-DC، Kubernetes، CDN، Disaster Recovery یا مانیتورینگ متمرکز نیاز دارد، طراحی DNS باید در کنار کل معماری Infrastructure انجام شود.

آلتیمیت کلاد می‌تواند طراحی و پیاده‌سازی زیرساخت DNS را در کنار سایر اجزای Infrastructure، امنیت، مانیتورینگ، High Availability و Disaster Recovery انجام دهد.

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