کلاستر چهار نیمسروری
رکوردهای شما روی چهار نیمسرور مستقل توزیع میشوند تا حتی با از دسترس خارجشدن یک نیمسرور، پاسخدهی دامنه قطع نشود.
مدیریت کامل رکوردها
افزودن، ویرایش و حذف رکوردهای A، AAAA، CNAME، MX و TXT بهصورت آنی از ناحیه کاربری، بدون نیاز به تیکت.
پایداری و امنیت
زیرساخت مستقل و پایدار برای پاسخگویی سریع به کوئریهای DNS و کاهش احتمال قطعی دامنه.
پلنها
پلنهای حرفهایتر با ظرفیت بالاتر بهزودی اضافه میشوند.
بیشتر بدانید
میزبانی DNS یا هاست DNS، سرویسی است که وظیفه نگهداری و پاسخگویی به رکوردهای دامنه شما را بر عهده دارد؛ یعنی وقتی کاربری آدرس سایت شما را در مرورگر وارد میکند، همین نیمسرورها هستند که نام دامنه را به آدرس آیپی سرور تبدیل میکنند تا سایت بالا بیاید. کیفیت و پایداری DNS مستقیماً روی سرعت باز شدن سایت و در دسترس بودن آن اثر میگذارد.
در آنلاین سرور، میزبانی DNS روی یک کلاستر اختصاصی متشکل از چهار نیمسرور مستقل ارائه میشود. توزیع رکوردها روی چند نیمسرور باعث میشود که پاسخدهی دامنه شما حتی در صورت بروز مشکل روی یکی از نیمسرورها بدون وقفه ادامه پیدا کند. مدیریت رکوردها (A، AAAA، CNAME، MX، TXT) نیز بهصورت کامل و آنی از ناحیه کاربری در اختیار شماست.
برای شروع، پلن رایگان با پشتیبانی از یک دامنه و تا ۲۰ رکورد ارائه میشود که برای سایتهای شخصی و پروژههای کوچک کافی است. پلنهای حرفهایتر با ظرفیت بالاتر بهزودی اضافه میشوند. اگر به مسیریابی جغرافیایی و لود بالانس نیاز دارید، سرویس تخصصی Geo DNS نیز بهصورت جداگانه ارائه میشود.
رکوردهای DNS و کاربرد هر کدام
هر رکورد در زون DNS به یک پرسش مشخص پاسخ میدهد: سایت روی کدام آیپی است، ایمیل دامنه به کدام سرور برود و چه چیزی برای تأیید مالکیت روی دامنه ثبت شده است. میزبانی DNS آنلاین سرور این پنج نوع رکورد را پوشش میدهد:
| نوع رکورد | چه کاری میکند | کجا به کارتان میآید |
|---|---|---|
| A | دامنه را به یک آدرس IPv4 وصل میکند. | اتصال دامنه و زیردامنهها به آیپی هاست لینوکس ایران یا سرور اختصاصی شما. |
| AAAA | همان کار رکورد A، برای آدرس IPv6. | وقتی سرور آیپی نسخه ۶ دارد و میخواهید کنار IPv4 در دسترس باشد. |
| CNAME | یک نام را به نام دیگری ارجاع میدهد. | زیردامنههایی مثل www و سرویسهایی که آیپیشان عوض میشود. |
| MX | تعیین میکند ایمیل دامنه به کدام سرور و با چه اولویتی برود. | راهاندازی ایمیل روی دامنه، روی هاست خودتان یا یک سرویس بیرونی. |
| TXT | متن آزاد را روی دامنه نگه میدارد. | رکوردهای SPF، DKIM و DMARC، و تأیید مالکیت دامنه در سرچ کنسول. |
سه رکورد دیگر هم در DNS پرکاربردند: NS که تعیین میکند یک زیرزون را کدام نیمسرورها اداره میکنند، SRV که نشانی و پورت یک سرویس مشخص را اعلام میکند، و CAA که مشخص میکند کدام مراجع صدور گواهی حق دارند برای دامنه شما گواهی صادر کنند. این سه، بههمراه مسیریابی جغرافیایی و لود بالانس، در سرویس Geo DNS ارائه میشوند.
رکورد CNAME کاربرد دیگری هم دارد که کمتر دیده میشود: اتصال دامنه به یک شبکهٔ توزیع محتوا. سرویس CDN آنلاین سرور مستقل از محل میزبانی دامنه است و تنها با یک CNAME وصل میشود؛ اگر زون دامنه روی نیمسرورهای Geo DNS ما باشد، همین رکورد بهصورت خودکار ساخته میشود و گواهی SSL هم خودکار صادر میشود.
SPF، DKIM و DMARC؛ سه رکورد TXT که ایمیل دامنه را نجات میدهند
رکورد TXT در جدول بالا یک سطر بیشتر نگرفت، ولی مهمترین کاربردش سه استاندارد احراز هویت ایمیل است. هر سرور گیرندهای — از سرویسهای ایمیل عمومی تا سرور ایمیل یک شرکت — پیش از آنکه نامهای را به صندوق ورودی تحویل بدهد، همین سه رکورد را روی دامنه فرستنده میخواند. اگر تعریف نشده باشند، نامههای خود شما شانس بیشتری برای افتادن در پوشه اسپم دارند و در عمل هر کسی میتواند با نام دامنه شما برای دیگران ایمیل بفرستد.
SPF — فهرست فرستندههای مجاز
یک رکورد TXT که اعلام میکند کدام سرورها حق دارند با نام دامنه شما ایمیل بفرستند. سرور گیرنده آیپی فرستنده را با همین فهرست مقایسه میکند و اگر در آن نبود، نامه را مشکوک میشمارد. برای هر دامنه فقط یک رکورد SPF باید وجود داشته باشد؛ اگر از چند جا ایمیل میفرستید — هاست، سرویس خبرنامه، سامانه فروش — همه باید داخل همان یک رکورد جمع شوند، نه در چند رکورد جدا.
DKIM — امضای دیجیتال روی هر نامه
سرور فرستنده هر نامه را با یک کلید خصوصی امضا میکند و کلید عمومی متناظرش را شما در یک رکورد TXT روی زیردامنهای مشخص (سلکتور) منتشر میکنید. گیرنده با همان کلید عمومی بررسی میکند که نامه واقعاً از دامنه شما آمده و در مسیر دستکاری نشده است. کلید را سرویس ایمیلتان تولید میکند؛ کار شما فقط ثبت همان رکورد در زون است.
DMARC — تعیین تکلیف نامههای مردود
رکوردی که به سرور گیرنده میگوید اگر نامهای SPF و DKIM را رد کرد چه کند: کاری نکن، به پوشه اسپم بفرست، یا کلاً تحویل نده. در همین رکورد میتوانید نشانیای برای دریافت گزارش تعیین کنید تا ببینید چه کسانی، از کجا، دارند با نام دامنه شما ایمیل میفرستند.
هیچکدام از این سه بهتنهایی کافی نیست: SPF میگوید چه کسی حق ارسال دارد، DKIM ثابت میکند نامه دستکاری نشده، و DMARC تعیین میکند با نامهای که این دو را رد کرد چه رفتاری بشود. ترتیب راهاندازی هم مهم است. اول SPF را بنویسید و مطمئن شوید همه سرویسهایی که واقعاً از طرف شما ایمیل میفرستند در آن دیده شدهاند. بعد DKIM را روی سرویس ایمیل فعال کنید و رکورد کلید عمومی را در زون ثبت کنید. در آخر DMARC را با سیاست p=none اضافه کنید؛ در این حالت هیچ نامهای رد نمیشود و شما فقط گزارش میگیرید. وقتی گزارشها نشان داد نامههای سالم خودتان همگی SPF یا DKIM را پاس میکنند، سیاست را پلهپله به quarantine و سپس reject سفت کنید. اگر از همان روز اول reject بگذارید، اولین چیزی که قربانی میشود ایمیلهای خودتان است: فاکتور، پیام بازیابی رمز و خبرنامهای که از یک سرویس بیرونی ارسال میشود. هر سه اینها رکورد TXT سادهاند و در همان پلن رایگان میزبانی DNS آنلاین سرور قابل ثبتاند.
زون دامنهتان کجا باشد؟
زون دامنه را میشود در سه جای مختلف نگه داشت و هر کدام پیامد متفاوتی دارد؛ تفاوت اصلی این است که با تعویض هاست یا ثبتکننده، چقدر از کارتان دوباره باید انجام شود:
DNS ثبتکننده دامنه
سادهترین حالت، ولی زون به همان ثبتکننده گره میخورد و با انتقال دامنه باید از نو ساخته شود.
DNS روی هاست یا کنترلپنل
همه چیز یکجاست، اما پاسخگویی DNS و در دسترس بودن سایت به یک زیرساخت واحد وابسته میشوند.
میزبانی DNS مستقل
زون روی کلاستر چهار نیمسروریِ جدا از هاست میماند؛ تعویض ثبتکننده یا مهاجرت به ویپیاس ایران فقط یک رکورد را عوض میکند، نه کل زون را.
میزبانی DNS مستقل به درد چه کسی میخورد؟
صادقانهاش این است که هر سایتی به DNS مستقل نیاز ندارد. برای بخش بزرگی از سایتهای کوچک، همان DNS ثبتکننده یا کنترلپنل هاست کار را راه میاندازد و اضافه کردن یک سرویس دیگر فقط یک جای دیگر میسازد که یادتان برود کجاست. تفاوت وقتی معنا پیدا میکند که دامنه بیش از یک مقصد داشته باشد، یا قرار باشد زیرساخت زیرِ آن روزی عوض شود.
احتمالاً به آن نیاز دارید، اگر…
- دامنهتان همزمان به چند مقصد وصل است: سایت روی یک سرور، ایمیل روی سرویسی دیگر، و چند زیردامنه برای پنل، استیجینگ یا اپلیکیشن موبایل.
- برنامه تعویض هاست یا ثبتکننده دارید و نمیخواهید هر بار کل زون را دستی از نو بسازید و ریسک جا افتادن یک رکورد را بپذیرید.
- چند دامنه را برای خودتان یا مشتریانتان مدیریت میکنید و میخواهید همه زونها در یک ناحیه کاربری جمع باشند.
- سایتتان درآمدزاست و ترجیح میدهید پاسخگویی DNS به همان زیرساختی که فایلهای سایت روی آن است گره نخورد.
- روی دامنه ایمیل سازمانی راه انداختهاید و مرتب با رکوردهای SPF، DKIM و DMARC سر و کار دارید.
احتمالاً لازمش ندارید، اگر…
- یک سایت ساده یا وبلاگ دارید که روی هاست خودش نشسته و قرار نیست جابهجا شود؛ مثلاً یک سایت وردپرسی روی هاست وردپرس ایران که در کل دو سه رکورد دارد.
- دامنه را تازه ثبت کردهاید و هنوز تصمیم نگرفتهاید سایت کجا بالا بیاید.
- کل نیازتان یک رکورد A و یک www است و سراغ ایمیل روی دامنه هم نمیروید.
- سرویسی که استفاده میکنید زون را خودش میسازد و مدیریت میکند و شما ترجیح میدهید همهچیز در همان یک پنل بماند.
اگر در ستون دوم هستید، جابهجا کردن زون هیچ فوریتی ندارد و بهتر است انرژیتان را جای دیگری بگذارید. هر وقت یکی از شرطهای ستون اول برایتان پیش آمد — مثلاً ایمیل سازمانی راه انداختید یا تصمیم گرفتید هاست را عوض کنید — همانموقع سراغ انتقال بروید؛ گامهای بیقطعیاش پایینتر آمده است.
TTL؛ عددی که تعیین میکند تغییر شما کِی دیده میشود
کنار هر رکورد DNS عددی به نام TTL هست که میگوید ریزالورهای اینترنت چند ثانیه اجازه دارند پاسخ را در حافظه نگه دارند. تا پایان این زمان، تغییر شما برای بخشی از کاربران دیده نمیشود؛ چیزی که «انتشار DNS» نامیده میشود در عمل همین منقضی شدن تدریجی کشهاست.
رکوردهایی که ماهها ثابت میمانند — مثل MX یا TXTِ تأیید مالکیت — میتوانند TTL بلند بگیرند؛ رکوردی که قرار است عوض شود بهتر است چند روز پیش از تغییر روی کوتاهترین مقدار ممکن قرار بگیرد. ترتیب مهم است: کاهش TTL باید پیش از تغییر رکورد انجام شود، نه همزمان با آن، وگرنه باز هم باید تا انقضای کش قبلی صبر کنید.
انتقال DNS بدون قطعی؛ گام به گام
جابهجایی زون نباید سایت یا ایمیل شما را از دسترس خارج کند؛ ترتیب کارها مهمتر از خودِ کارهاست.
- ۱
فهرست رکوردهای فعلی را بردارید
MX و TXTهای SPF و DKIM را جا نیندازید؛ فراموش شدن همینها شایعترین دلیل قطع شدن ایمیل بعد از انتقال است.
- ۲
چند روز قبل، TTL را پایین بیاورید
در سرویس فعلی TTL را کم کنید و صبر کنید کش قبلی منقضی شود تا پنجرهی ناهماهنگی بعد از سوئیچ کوتاه بماند.
- ۳
زون جدید را پیش از تعویض نیمسرورها بسازید
دامنه را در ناحیه کاربری اضافه کنید و رکوردها را عیناً وارد کنید، سپس مستقیماً از نیمسرورهای جدید کوئری بگیرید؛ هنوز ترافیکی جابهجا نشده و اشتباهها بیهزینهاند.
- ۴
نیمسرورها را در پنل ثبتکننده عوض کنید
نیمسرورهای نمایشدادهشده در ناحیه کاربری را جایگزین قبلیها کنید. اگر تازه دامنه میگیرید، تعرفهها در صفحه ثبت دامنه آمده است.
- ۵
زون قدیمی را بلافاصله حذف نکنید
یکی دو روز زون قبلی را دستنخورده نگه دارید؛ تا بهروز شدن کامل کش ریزالورها، بخشی از کاربران هنوز از آن پاسخ میگیرند.
وقتی چیزی درست کار نمیکند؛ نشانه، علت، راهحل
خرابیهای DNS تقریباً همیشه چند الگوی تکراری دارند و تفاوتشان در این است که مشکل از کش است، از رکورد اشتباه، یا از اینکه اصلاً زون درست را ویرایش نمیکنید. جدول زیر نشانههایی را که معمولاً گزارش میشوند به محتملترین علت و اولین کاری که باید انجام دهید وصل میکند:
| نشانه | علت محتمل | چه کار کنید |
|---|---|---|
| سایت برای بعضی کاربران باز میشود و برای بعضی نه | کش ریزالورها هنوز پاسخ قدیمی را نگه داشتهاند، یا همه نیمسرورهای زون رکورد یکسانی ندارند. | از چند ریزالور مختلف مستقیماً کوئری بگیرید و پاسخ نیمسرورها را با هم مقایسه کنید. اگر همه یک چیز میگویند، مسئله فقط منقضی نشدن کش قبلی است و باید صبر کرد؛ اگر پاسخها یکی نیست، رکورد روی همه نیمسرورها ثبت نشده است. |
| رکورد را عوض کردهام ولی «اعمال نمیشود» | TTL آن رکورد پیش از تغییر بالا بوده و کش هنوز منقضی نشده، یا تغییر را در زونی دادهاید که دیگر زون مرجع دامنه نیست. | اول مستقیماً از نیمسرورهای مرجع کوئری بگیرید و ببینید مقدار جدید آنجا هست یا نه. اگر هست، فقط کش مانده است. اگر نیست، نیمسرورهای ثبتشده در پنل ثبتکننده را نگاه کنید؛ به احتمال زیاد زون فعال جای دیگری است و شما دارید نسخهای را ویرایش میکنید که کسی از آن کوئری نمیگیرد. |
| ایمیل دامنه ناگهان قطع شده | بعد از تعویض نیمسرور یا ساختن دوباره زون، رکوردهای MX و TXTهای SPF و DKIM منتقل نشدهاند. | زون جدید را با فهرستی که پیش از انتقال برداشتهاید تطبیق دهید و هر MX و TXT جامانده را دوباره اضافه کنید. تا وقتی زون قدیمی را حذف نکردهاید، مقادیر دقیق را میتوانید از همانجا بردارید — همین یک دلیل است که زون قبلی نباید بلافاصله پاک شود. |
| www باز میشود ولی دامنه بدون www نه (یا برعکس) | فقط یکی از این دو نام رکورد دارد. ریشه دامنه و زیردامنه www دو نام جدا در زوناند و هیچکدام بهطور خودکار دیگری را پوشش نمیدهد. | برای ریشه دامنه رکورد A (و در صورت داشتن آیپی نسخه ۶، رکورد AAAA) و برای www یک CNAME به ریشه تعریف کنید. بعد در سطح وبسرور یکی را به دیگری ریدایرکت کنید تا فقط یک نسخه نشانی رسمی سایت باشد. |
| صدور گواهی SSL شکست میخورد | نام دامنه هنوز به سروری که درخواست گواهی از آن انجام میشود اشاره نمیکند، یا رکورد CAA روی دامنه به آن مرجع صدور گواهی اجازه نمیدهد. | اول رکورد A همان نام دقیق (با و بدون www، هر کدام که در گواهی خواسته شده) را بررسی کنید. بعد سراغ CAA بروید: نداشتن هیچ رکورد CAA مانع صدور نیست، ولی اگر CAA دارید و نام آن مرجع در آن نیامده باشد، درخواست رد میشود. |
| یک زیردامنه به سرور اشتباه میرود | رکورد قدیمی همان زیردامنه هنوز در زون مانده، یا رکوردی حذف شده و یک رکورد wildcard جایش را پر کرده است. | زون را برای رکوردهای تکراریِ همان نام و برای رکورد ستارهدار (*) بگردید. رکورد دقیقِ یک نام همیشه بر wildcard مقدم است، پس اگر رکورد اختصاصی پاک شده باشد، پاسخ از wildcard میآید و کاربر روی سرور اشتباه مینشیند. |
یک نکته که در همه این موارد تکرار میشود: پیش از هر تغییری، مستقیماً از نیمسرورهای مرجع دامنه کوئری بگیرید، نه از ریزالوری که مرورگر یا سیستمعامل شما استفاده میکند. آنچه ریزالور محلی نشان میدهد ممکن است پاسخ کششده ساعتها پیش باشد و شما را دنبال مشکلی بفرستد که وجود ندارد. اگر به ابزار دمدستی نیاز دارید، چکاپ رایگان سایت همین کوئریها را از بیرون شبکه شما میگیرد و پاسخ نیمسرورها، وضعیت گواهی و ریدایرکتها را در یک گزارش کنار هم نشان میدهد.
چرا آنلاین سرور؟
ضامن امنیت شما
امنیت اطلاعات کاربران یکی از اولویتهای آنلاین سرور است. به همین منظور، با بهرهگیری از راهکارهایی مانند گواهی SSL، فایروالهای امنیتی، لایسنس CXS و تهیه نسخههای پشتیبان (Backup)، بستری امنتر برای میزبانی وبسایتها و سرورها فراهم شده است. این زیرساختها به افزایش امنیت سرویسها، محافظت از اطلاعات و کاهش ریسک بروز مشکلات احتمالی کمک میکنند.
پشتیبانی 24 ساعته
پایداری سرویسها و دسترسی همیشگی به وبسایت، یکی از مهمترین نیازهای هر کسبوکار آنلاین است. به همین دلیل، تیم پشتیبانی آنلاین سرور بهصورت ۲۴ ساعته و در تمام روزهای هفته آماده پاسخگویی و رسیدگی به درخواستهای کاربران است تا مشکلات و نیازهای فنی در کوتاهترین زمان ممکن بررسی و پیگیری شوند.
بالاترین آپتایم
آنلاین سرور با بهرهگیری از زیرساختهای قدرتمند، سختافزارهای بهروز و همکاری با دیتاسنترهای معتبر داخلی و بینالمللی، بستری پایدار و قابلاعتماد برای میزبانی سرویسها فراهم کرده است. هدف ما ارائه آپتایم ۹۹٪ و حفظ پایداری سرویسهاست تا وبسایتها و کسبوکارهای آنلاین با کمترین میزان قطعی، همواره در دسترس کاربران باشند.
سرعت لود بالای سایت شما
سرعت بارگذاری وبسایت یکی از عوامل مهم در بهبود تجربه کاربری و سئو است. آنلاین سرور با بهرهگیری از زیرساختهای بهروز، سختافزارهای قدرتمند و سرویسهای میزبانی بهینه، بستر مناسبی برای افزایش سرعت وبسایت شما فراهم میکند. همچنین برای دستیابی به عملکرد بهتر، امکان استفاده از لایسنس LiteSpeed نیز برای کاربران فراهم شده است. البته سرعت نهایی وبسایت به عواملی مانند بهینهسازی سایت، قالب، افزونهها و نحوه توسعه آن نیز بستگی دارد.
سوالات متداول
میزبانی DNS چیست و چه کاربردی دارد؟
نیمسرورهای آنلاین سرور روی چه زیرساختی قرار دارند؟
پلن رایگان چه محدودیتی دارد؟
چطور دامنهام را به میزبانی DNS آنلاین سرور وصل کنم؟
تفاوت میزبانی DNS با سرویس Geo DNS چیست؟
چه نوع رکوردهایی در این سرویس پشتیبانی میشوند؟
بعد از تغییر یک رکورد، چقدر طول میکشد تا همهجا اعمال شود؟
آیا میزبانی DNS جای هاست یا ثبت دامنه را میگیرد؟
برخی از مشتریان ما
آدرس دفاتر ما
دفتر تهران(نیاز به هماهنگی از طریق تیکت)
خیابان مطهری - خیابان علی اکبری - خیابان صحاف زاده - پلاک ۱۷ -واحد ۱/۱دفتر استانبول(نیاز به هماهنگی از طریق تیکت)
Yeşılköy Mah - Atatürk Cad - EGS Busıness Park - Apt No ۱۲/۱ - Onlıne Server Telekomünıkasyon - Bakırköy/Isatnbul - Turkeyدفتر شهریار(نیاز به هماهنگی از طریق تیکت)
تهران – شهریار – خیابان کرشته – پلاک ۱۰۱ – مجتمع اداری نور – طبقه سوم – واحد ۱۲تماس با ما
شماره تماس
ساعات پشتیبانی تلفنی
ایمیل و تیکت (۲۴ ساعته)
مجوزها و نمادها
