دامنه و DNS چطور کار میکنند: راهنمای افراد غیرتوسعهدهنده
دامنه همان نامی است که مردم برای رسیدن به سایت شما تایپ میکنند، مثل example.com، و DNS (سیستم نام دامنه) دفترچهی تلفن اینترنت است که آن نام را به جایی که سایت شما واقعاً در آن قرار دارد ترجمه میکند. دامنه را از یک ثبتکننده اجاره میکنید، سپس رکوردهای DNS اضافه میکنید که میگویند «وبسایت آنجاست» و «ایمیل به اینجا میرود». اتصال یک دامنهی اختصاصی به یک اپ عمدتاً یعنی افزودن رکورد درست در جای درست و صبر کردن تا اثر کند.
چرا وقتی با هوش مصنوعی میسازید مهم است
یک ساز اپ با هوش مصنوعی میتواند اپ شما را بنویسد و میزبانی کند، اما دامنهی شما بیرون از آن زندگی میکند — اغلب نزد شرکتی جدا، در یک پنل کنترل پر از نوع رکوردهای ناآشنا. اینجاست که بسیاری از لانچها متوقف میشوند: اپ آماده است، اما دامنه خطا نشان میدهد، یا بعد از یک تغییر DNS ایمیل بهطور مرموزی از کار میافتد.
کمی شناخت خیلی کمک میکند. میدانید میزبان شما کدام رکورد را میخواهد، چرا هنوز کار نکرده، و چطور چیزهایی را که از قبل به دامنهتان وابستهاند (مثل ایمیل) خراب نکنید.
یک تشبیه روزمره
فهرست مخاطبین گوشیتان را در نظر بگیرید.
شمارهی دوستتان را حفظ نیستید؛ روی نامش ضربه میزنید و گوشی آن را پیدا میکند. DNS برای اینترنت همین کار را میکند: شما example.com را تایپ میکنید و DNS شماره (آدرس IP) سروری را که باید به آن وصل شوید پیدا میکند.
- دامنه نام مخاطب است.
- ثبتکننده شرکتی است که رسماً ثبت میکند که این نام مال شماست.
- رکوردهای DNS اطلاعاتی هستند که زیر آن نام ذخیره شده: شماره تلفن، ایمیل، آدرس.
- نامسرورها مشخص میکنند کدام دفترچهی مخاطبین رسمی برای آن نام است.
- کش یعنی گوشی شما یک شماره را برای مدتی به خاطر میسپارد. اگر دوستتان شمارهاش را عوض کند، برخی گوشیها تا وقتی نسخهی ذخیرهشدهشان تازه نشود به شمارهی قدیمی زنگ میزنند — این همان "انتشار" DNS است.
اجزای یک نام دامنه
app.example.com را در نظر بگیرید:
| بخش | نام | توضیح |
|---|---|---|
.com | دامنهی سطح بالا (TLD) | توسط یک رجیستری اداره میشود. دیگران شامل .org، .io، .ai و کدهای کشوری مثل .uk هستند |
example | دامنهی سطح دوم | بخشی که ثبت میکنید |
example.com | دامنهی اصلی یا "apex" | چیزی که مالکش هستید |
app | زیردامنه | آزادانه در DNS میسازید — www، app، shop |
دامنه را بهطور کامل نمیخرید؛ آن را برای یک دوره (معمولاً یک سال یا بیشتر) ثبت میکنید و تمدید میکنید. اگر اجازه دهید منقضی شود، کس دیگری میتواند آن را ثبت کند.
جستجوی DNS چطور کار میکند
وقتی کسی app.example.com را تایپ میکند:
- مرورگر از یک resolver DNS — که معمولاً توسط ارائهدهندهی اینترنت یا یک سرویس عمومی اداره میشود — آدرس را میپرسد.
- اگر resolver یک پاسخ کششده و تازه داشته باشد، فوراً جواب میدهد.
- اگر نه، در سلسلهمراتب پایین میرود: سرورهای ریشه او را به سرورهای
.comهدایت میکنند، که او را به نامسرورهای دامنهی شما میفرستند. - نامسرورهای شما رکوردی را که تنظیم کردهاید برمیگردانند، مانند یک CNAME به میزبانتان یا یک رکورد A با یک آدرس IP.
- resolver پاسخ را برای مدت TTL (زمان زنده ماندن) رکورد کش میکند و به مرورگر میدهد، که به سرور وصل میشود.
این کل فرآیند معمولاً در میلیثانیه انجام میشود.
انواع رکوردهای DNS که واقعاً استفاده میکنید
| رکورد | کارش | مثال |
|---|---|---|
| A | یک نام را به یک آدرس IPv4 وصل میکند | example.com → 203.0.113.10 |
| AAAA | یک نام را به یک آدرس IPv6 وصل میکند | example.com → 2001:db8::10 |
| CNAME | یک نام را نام مستعار یک میزبان دیگر میکند | app.example.com → myapp.host.com |
| MX | مشخص میکند کدام سرورها ایمیل دامنه را دریافت میکنند، با یک عدد اولویت | example.com → 10 mail.provider.com |
| TXT | متن نگه میدارد، برای تأیید مالکیت و امنیت ایمیل استفاده میشود | v=spf1 include:_spf.provider.com ~all |
| NS | نامسرورهای معتبر دامنه را فهرست میکند | ns1.dnsprovider.com |
| CAA | محدود میکند کدام مراجع صدور گواهی میتوانند گواهی HTTPS صادر کنند | 0 issue "letsencrypt.org" |
چند قاعده که ارزش دانستن دارند:
- یک CNAME نمیتواند با رکوردهای دیگر یک نام مشترک داشته باشد. به همین دلیل CNAME استاندارد نمیتواند روی دامنهی اصلی بنشیند، که همیشه NS و رکوردهای دیگر دارد. بسیاری از ارائهدهندگان DNS راهحلهایی به نام ALIAS، ANAME یا CNAME flattening ارائه میدهند.
- رکوردهای TXT کار زیادی برای ایمیل انجام میدهند. SPF مشخص میکند چه کسانی مجازند برای دامنهی شما ایمیل بفرستند؛ DKIM یک کلید برای تأیید امضاها منتشر میکند؛ DMARC به گیرنده میگوید با ایمیلی که این بررسیها را رد میکند چه کند.
- عدد MX کمتر یعنی اولویت بالاتر. ایمیل ابتدا کمترین را امتحان میکند.
انتشار و TTL
"انتشار" این تصور را میدهد که تغییرات بهآرامی در اینترنت پخش میشوند. در واقع کش در کار است: resolver ها هر پاسخ را برای TTL آن نگه میدارند و فقط وقتی دوباره میپرسند که منقضی شده باشد. پس:
- یک رکورد جدید که هرگز جستجو نشده، اغلب در عرض چند دقیقه کار میکند.
- تغییر یک رکورد موجود تا رسیدن TTL قدیمی آن در همه جا دیده نمیشود.
- تغییر نامسرورها ممکن است تا یک یا دو روز طول بکشد، چون این رکوردها در سطح TLD برای مدت طولانیتری کش میشوند.
یک ترفند مفید: قبل از یک تغییر برنامهریزیشده، TTL رکورد را پایین بیاورید (مثلاً چند دقیقه)، صبر کنید TTL قدیمی بگذرد، و بعد تغییر را انجام دهید.
یک مثال کامل: وصل کردن یک اپ رزرو به دامنهتان
شما صاحب yoursalon.com هستید. وبسایت فعلیتان و ایمیل Google Workspace از قبل از آن استفاده میکنند. یک اپ رزرو ساختهاید و میخواهید در book.yoursalon.com باشد.
- پیدا کنید DNS شما کجا مدیریت میشود. ممکن است ثبتکنندهتان باشد یا یک ارائهدهندهی DNS جدا. رکوردهای NS شما این را نشان میدهند.
- یک CNAME برای
bookاضافه کنید که به مقصدی که میزبان اپ به شما میدهد اشاره کند. - هر رکورد TXT که میزبان برای اثبات مالکیت میخواهد اضافه کنید، اگر از آن استفاده میکند.
- رکوردهای MX و TXT ایمیل را دست نزنید. ایمیل کار میکند چون به آن دست نزدهاید.
- در میزبانتان تأیید کنید وقتی DNS بهروز شد. سپس میزبان یک گواهی HTTPS برای
book.yoursalon.comصادر میکند. - تست کنید روی گوشی با دادهی موبایل، چون از resolver و کش متفاوتی نسبت به وایفای خانه استفاده میکند.
اگر میخواستید اپ روی دامنهی اصلی yoursalon.com باشد، به رکوردهای A یا قابلیت ALIAS/flattening ارائهدهندهی DNS خود نیاز داشتید — و در آن صورت وبسایت فعلیتان را آنجا جایگزین میکردید. برای مراحل بیشتر، چطور یک دامنهی اختصاصی وصل کنیم را ببینید.
اشتباهات و باورهای غلط رایج
- "دامنه و میزبانی یک چیز هستند." دامنه نام است؛ میزبانی جایی است که اپ اجرا میشود. DNS این دو را به هم وصل میکند.
- استفاده از رکورد A وقتی میزبان CNAME خواسته (یا برعکس). دقیقاً دستورالعمل میزبان را دنبال کنید.
- غلط تایپی در مقصد. یک کاراکتر اشتباه در مقصد CNAME باعث شکست تأیید میشود.
- تغییر نامسرورها بدون کپی رکوردها. انتقال DNS به یک ارائهدهندهی جدید بدون ساختن دوبارهی رکوردهای MX و TXT، روش کلاسیک خراب کردن ایمیل است.
- پراکسی کردن وقتی نباید. برخی ارائهدهندگان DNS، مثل Cloudflare، میتوانند ترافیک را پراکسی کنند. برخی میزبانها نیاز دارند رکورد روی "DNS only" باشد تا بتوانند گواهی صادر کنند.
- حذف رکوردهای TXT "ناشناس". آنها اغلب رکوردهای تأیید یا امنیت ایمیل هستند که چیزی به آنها وابسته است.
- اجازه دادن به منقضی شدن دامنه. تمدید خودکار را روشن کنید و کارت پرداخت را بهروز نگه دارید.
از ساز اپ هوش مصنوعیتان چه بخواهید
DNS بیرون از کد شما زندگی میکند، پس بیشتر دربارهی این است که چه چیزی بپرسید:
- "برای app.mydomain.com دقیقاً چه رکورد DNSی لازم دارم — نوع، نام و مقدار؟"
- "آیا این تغییر روی ایمیل من تأثیر میگذارد؟"
- "بعد از افزودن رکورد، دامنه خطا نشان میدهد. چه چیزهایی را باید بررسی کنم؟"
- "آدرس canonical و ریدایرکتهای درست اضافه کن تا www و غیر www هر دو سایت را نشان ندهند."
- "ارسال ایمیل از دامنهام را راهاندازی کن — کدام رکوردهای SPF، DKIM و DMARC لازم است؟" چطور از اپ خود ایمیل ارسال کنیم را ببینید.
دامنههای اختصاصی در Mythex
هر اپ منتشرشده در Mythex یک نشانی yourname.mythex.app میگیرد. در طرح Pro میتوانید بهجای آن از دامنهی اختصاصی خودتان استفاده کنید: یک دامنه را داخل Mythex بخرید (ثبت آن جداگانه صورتحساب میشود، و DNS دامنههای خریداریشده برای شما مدیریت میشود)، یا دامنهای را که از قبل دارید با افزودن یک CNAME از یک زیردامنه مثل app.example.com به نشانی yourname.mythex.app اپ خود وصل کنید، و سپس روی Verify کلیک کنید. HTTPS بهطور خودکار صادر میشود. اگر DNS شما روی Cloudflare است، آن رکورد را روی "DNS only" بگذارید. زیردامنهها توصیه میشوند؛ دامنههای اصلی به پشتیبانی ALIAS یا flattening ارائهدهندهی DNS شما بستگی دارند. مستندات دامنهی اختصاصی هر مرحله را توضیح میدهد، و قیمت نشان میدهد Pro چه چیزهایی دارد.
پرسشها
DNS به زبان ساده چیست؟
DNS (سیستم نام دامنه) دفترچهی تلفن اینترنت است. یک نام قابلیادآوری مثل example.com را به اطلاعاتی که کامپیوترها لازم دارند — معمولاً یک آدرس IP — تبدیل میکند تا مرورگر سرور درست را پیدا کند.
تفاوت رکورد A و CNAME چیست؟
رکورد A یک نام را مستقیم به یک آدرس IPv4 وصل میکند. رکورد CNAME یک نام را به نام میزبان دیگری وصل میکند و جستجو از آنجا ادامه پیدا میکند. CNAME وقتی آدرسهای IP میزبان شما ممکن است تغییر کنند مفید است، اما CNAME استاندارد روی خود دامنهی اصلی (root) قابل استفاده نیست.
انتشار DNS چقدر طول میکشد؟
اغلب چند دقیقه، گاهی چند ساعت. تغییرات وقتی دیده میشوند که نسخههای کششدهی رکورد قدیمی منقضی شوند، و این به TTL رکورد بستگی دارد. تغییر نامسرورها ممکن است یک یا دو روز طول بکشد، چون این رکوردها برای مدت طولانیتری کش میشوند.
آیا تغییر DNS وبسایتم ایمیلم را خراب میکند؟
فقط اگر رکوردهایی را که ایمیل به آنها وابسته است تغییر دهید یا حذف کنید — یعنی رکوردهای MX و رکوردهای TXT مثل SPF، DKIM و DMARC. اضافه کردن یک CNAME برای www یا app ایمیل را دستنخورده میگذارد. انتقال دامنه به نامسرورهای جدید اگر این رکوردها را قبلاً کپی نکنید میتواند ایمیل را از کار بیندازد.
چرا بهجای دامنهی اصلی از www یا app استفاده کنیم؟
یک زیردامنه مثل www.example.com یا app.example.com میتواند از CNAME استفاده کند، که چیزی است که بسیاری از پلتفرمهای میزبانی میخواهند. دامنهی اصلی (example.com) نمیتواند CNAME استاندارد داشته باشد، پس به رکوردهای A یا یک قابلیت مخصوص ارائهدهنده مثل ALIAS، ANAME یا CNAME-flattening نیاز دارد.