پرش به محتوا

سامانه نام دامنه

از ویکی‌پدیا، دانشنامهٔ آزاد
(تغییرمسیر از DNS)

سامانهٔ نام دامنه با کوته‌نوشت دی‌اِن‌اِس [الف] یا ساناد[۲]، یک سیستم فضای نام سلسه‌مراتبی نام‌گذاری برای کامپیوترها، سرویس‌ها، یا منابع دیگر است که به شبکه اینترنت یا یک شبکه خصوصی (LAN) متصل هستند. این سامانه نامتمرکز امکان ترجمه (یا نگاشت) یک نام دامنه (مثلا به یک نشان آی‌پی) را فراهم می‌کند. در واقع سامانهٔ نام دامنه، پروتکل اینترنتی است که نام های وب‌سایت‌ های قابل خواندن برای انسان را به آدرس‌ های عددی قابل خواندن توسط ماشین تبدیل می‌کند.[۳]

برای مثال، وقتی می‌خواهید وارد وبگاهی شوید، باید نشانی کارساز وبش را بدانید. نشانی کارساز وب با نشانی آی‌پی مشخص می‌شود. اما به خاطر سپردن نشانی آی‌پی، دشوار است. می‌توان به جای نشانی آی‌پی، از نام‌های دامنه استفاده کرد. مثلاً یکی از نشانی‌های آی‌پی وبگاه گوگل 172.217.16.68 است.برای دسترسی به گوگل، می‌توانید از این نشانی آی‌پی یا نام دامنه آن یعنی www.google.com استفاده کنید.[۴][۵]

ساختار نام

[ویرایش]
ساختار نام دامنه www.example.com. هر نام دامنه متشکل است از تعدادی برچسب که با نقطه از یکدیگر جدا می‌شوند. بالاترین برچسب از آن حوزه ریشه است که برچسبی خالی است. بعد از برچسب دامنه‌های سطح بالا (در اینجا com)، سطح دوم و غیره. دقت شود که «زیردامنه» عبارتی کلّی است که اشاره هر زیرمجموعه‌ای از یک فضای نام دامنه دارد: همانطور که www زیردامنه example.com است، example هم زیردامنه‌ای از (فضای نام) com است.

مشخصات فنی اولیه ساناد[۶] ساختاری مشخص برای نام‌ها در این فضا تعریف می‌کند. هر نام شامل یک یا چند برچسب (انگلیسی: label) است که با نقطه (.) از یکدیگر جدا می‌شوند. برچسب‌ها محدود به اعداد، حروف و یا خط پیوند (با کدگذاری اسکی) هستند.[۷][۸][۹] این قوانین نامگذاری در فرم باکوس نائور به شرح زیر تعریف می‌شوند:[۱۰]

<domain>      ::= <subdomain> | " "

<subdomain>   ::= <label> | <subdomain> "." <label>

<label>       ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str>     ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig>      ::= <letter> | <digit>

<letter>       ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit>        ::= any one of the ten digits 0 through 9

تنها برچسب خالی، نام دامنه ریشه (انگلیسی: root domain name) است (رجوع شود به خط شماره یک در تعریف بالا).[۱۱] برچسب بعدی نام یکی از دامنه‌های سطح‌بالا (مثلا com)، برچسب بعدی نام دامنه سطح‌دوم (مثلا example) است و غیره. به صورت کلی هر برچسب نام یک «زیر‌دامنه» را مشخص می‌کند، ولی در استفاده عام معمولا به برچسبی که دامنه بعد از سطح‌دوم را مشخص می‌کند (مثال در تصویر بالا) زیر‌دامنه و به دامنه سطح‌دوم به طور خلاصه «دامنه» می‌گویند.[۱۲][۱۳]

کاربرد

[ویرایش]

در ساناد، کل نشانی‌های اینترنت درون بانک‌های اطلاعاتی توزیع شده‌ای هستند که هیچ تمرکزی روی نقطه‌ای خاص از شبکه ندارند. روش ترجمهٔ نام بدین صورت است که وقتی یک برنامهٔ کاربردی مجبور است برای برقراری یک ارتباط، معادل نشانی آی‌پی از یک ماشین با نامی مثل cs.ucsb.edu را به‌دست بیاورد، قبل از هر کاری یک تابع کتابخانه‌ای (به انگلیسی: Library Function) را صدا می‌زند، به این تابع کتابخانه‌ای تابع تحلیلگر، نام (به انگلیسی: Name Resolver) گفته می‌شود.[۱۴]

تابع تحلیلگر، نام یک نشانی نمادین را که بایستی ترجمه شود، به عنوان پارامتر ورودی پذیرفته و سپس یک بستهٔ درخواست (به انگلیسی: Query Packet) به روش UDP تولید کرده و به نشانی یک کارساز DNS (که به صورت پیش‌فرض مشخص می‌باشد) ارسال می‌کند. همهٔ ماشین‌های میزبان، حداقل باید یک نشانی آی‌پی از یک سرویس دهندهٔ ساناد را در اختیار داشته باشند. این «سرویس دهندهٔ محلی» پس از جستجو، نشانی آی‌پی معادل با یک نام نمادین را برمی‌گرداند.[۱۵]

«تابع تحلیلگر نام» نیز آن نشانی آی‌پی را به برنامهٔ کاربردی تحویل می‌دهد با پیدا شدن نشانی آی‌پی، برنامهٔ کاربردی می‌تواند عملیات مورد نظرش را ادامه دهد.

کاربرد حوزه‌ها

[ویرایش]

برای تحلیل یک نام حوزه، سطوح از سمت راست به چپ تفکیک می‌شوند و در یک روند سلسله مراتبی، سرویس دهندهٔ متناظر با آن سطح پیدا می‌شود.

نام‌های حوزه به هفت منطقهٔ عمومی و حدود صد و اندی منطقهٔ کشوری تقسیم‌بندی شده‌است. حوزه بدین معناست که شما با یک نگاه ساده به انتهای نشانی نمادین، می‌توانید ماهیت آن نام و سرویس دهندهٔ متناظر با آن را حدس بزنید. یعنی اگر انتهای نام‌های حوزه متفاوت باشد منطقهٔ جستجو برای یافتن نشانی آی‌پی معادل نیز متفاوت خواهد بود.[۱۶][۱۷]

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

  • com. صاحب این نام جزو موسسات اقتصادی و تجاری به‌شمار می‌آید.
  • edu. صاحب این نام جزو موسسات علمی یا دانشگاهی به‌شمار می‌آید.
  • gov. این مجموعه از نام‌ها برای آژانس‌های دولتی آمریکا اختصاص داده شده‌است.
  • int. صاحب این نام یکی از سازمان‌های بین‌المللی (مثل یونسکو، فائو، ...) است.
  • mil. صاحب این نام یکی از سازمان‌های نظامی دنیا به‌شمار می‌آید.
  • net. صاحب این نام جزو یکی از «ارائه دهندگان خدمات شبکه» به‌شمار می‌رود.
  • org. صاحب این نام جزو یکی از سازمان‌های غیرانتفاعی محسوب می‌شوند.

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

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

هر حوزه می‌تواند به زیر حوزه‌های کوچکتری تقسیم شود، که به آن دامنه سطح دوم نیز گفته می‌شود.

به عنوان مثال، نام‌های مربوط به حوزه ایران، که با مخفف ir. مشخص می‌شود، به ۷ زیرحوزه، به شرح زیر تقسیم می‌شود:

  • ac.ir. : فقط برای دانشگاه‌ها یا موسسه‌های آموزشی
  • co.ir. : فقط برای شرکت‌های سهامی خاص، سهامی عام، مسوولیت محدود و تضامنی
  • gov.ir. : فقط برای مؤسسه‌ها یا سازمان‌های دولتی
  • id.ir. : فقط برای افراد دارای ملیت ایرانی
  • net.ir. : فقط برای سرویس دهندگان رسمی اینترنت
  • org.ir. : فقط برای مؤسسه‌ها و سازمان‌های خصوصی
  • sch.ir. : فقط برای مدارس

به‌عنوان مثال: http://eng.ut.ac.ir

  • کشور: ایران
  • هویت: دانشگاه
  • نام دانشگاه: ut مخففی برای نام دانشگاه تهران
  • نام دانشکده: eng مخففی برای بخش فنی مهندسی

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

روش‌های جستجو

[ویرایش]
نحوه دسترسی به یک سرور از طریق سامانه DNS

همانگونه که اشاره شد، اسامی نمادین در شبکه اینترنت که خود در قالب حوزه‌ها و زیر حوزه‌ها سازماندهی شده‌اند، در یک فایل متمرکز ذخیره نمی‌شوند بلکه روی کل شبکه اینترنت توزیع شده‌اند، به همین دلیل برای ترجمه یک نام به نشانی آی‌پی ممکن است چندین مرحله «پرس و جو» صورت بگیرد تا یک نشانی پیدا شود.[۱۸]

طبیعی است که یک پرس و جو برای تبدیل یک نام حوزه همیشه موفقیت‌آمیز نباشد و ممکن است به پرس و جوهای بیشتری نیاز شود یا حتی ممکن است یک نشانی نمادین اشتباه باشد و هیچ معادل نشانی آی‌پی نداشته باشد.[۱۹]

سه روش برای پرس و جوی نام در سرویس دهنده‌های نام وجود دارد:[۲۰]

پرس و جوی تکراری

[ویرایش]

در پرس و جوی تکراری قسمت اعظم تلاش برای تبدیل یک نام بر عهده سرویس دهنده محلی است؛ این DNS حداقل به نشانی ماشین Root، به عنوان نقطه شروع نیاز دارد. وقتی یک تقاضای ترجمه نشانی به سرویس دهنده محلی ارسال می‌شود در صورتی که قادر به ترجمه نام به معادل نشانی آی‌پی آن باشد، معادل نشانی آی‌پی نام مورد نظر را به تقاضاکننده برمی‌گرداند. (این حالت وقتی است که سرویس دهنده محلی قبلاً آن نام را ترجمه و در یک فایل ذخیره کرده باشد) در غیر این صورت سرویس دهنده محلی خودش یک تقاضا برای DNS سطح بالا ارسال می‌کند. این سرویس دهنده، نشانی ماشینی را که می‌تواند برای ترجمه نام مورد نظر مفید باشد، به سرویس دهنده محلی معرفی می‌کند؛ سرویس دهنده محلی مجدداً یک تقاضا به ماشین معرفی شده در مرحله قبل ارسال می‌کند.[۲۱]

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

این روند ادامه می‌یابد تا DNS نهایی نام مورد نظر را به نشانی آی‌پی ترجمه نماید. برای درک بهتر از روند کار به شکل زیر دقت کنید. در این مثال فرض شده‌است که یک برنامه کاربردی با فراخوانی «تابع تحلیلگر نام»، تقاضای ترجمه نام www.microsoft.com را می‌نماید. مراحلی که انجام می‌شود به شرح زیر است:

  • در مرحله اول برنامه کاربردی با فراخوانی «تابع تحلیل نام»، تقاضای ترجمه نشانی www.microsoft.com را برای سرویس دهنده محلی ارسال کرده و منتظر می‌ماند.
  • در مرحله دوم، سرویس دهنده محلی از سرویس دهنده Root (که حوزه‌های متفاوت را تفکیک می‌کند) نشانی ماشین یک DNS که متولی حوزه.com است را سؤال می‌کند.
  • در مرحله سوم، نشانی سرویس دهنده مربوط به حوزه. com بر می‌گردد.
  • در مرحله چهارم، سرویس دهنده محلی، از ماشین معرفی شده در مرحله قبلی، نشانی سرویس دهنده مربوط به حوزه Microsoft.com را سؤال می‌نماید.
  • در مرحله پنجم فهرستی از سرویس دهنده‌های DNS مربوط به Microsoft.com بر می‌گردد.
  • در مرحله ششم، سرویس دهنده محلی تقاضای ترجمه نشانی نمادین www.microsoft.com را از DNS متعلق به حوزه Microsoft.com می‌کند.
  • در مرحله هفتم، معادل نشانی آی‌پی نام www.microsoft.com برمی گردد.
  • در مرحله هشتم، نشانی آی‌پی خواسته شده در اختیار برنامه کاربردی قرار می‌گیرد.

پرس و جوی بازگشتی

[ویرایش]

در این روش هر گاه برنامه‌ای بخواهد نشانی آی‌پی معادل یک نام مثل cs.yale.edu را به‌دست آورد، بگونه‌ای که قبلاً اشاره شد، «تابع سیستمی تحلیل نام» را فراخوانی می‌کند. این تابع یک ماشین را به عنوان سرویس دهنده محلی از قبل می‌شناسد و بنابراین تقاضای تبدیل نام را به روش UDP برای آن ارسال کرده و منتظر جواب می‌ماند (پاسخ نهایی DNS طبیعتاً باید یک نشانی ۳۲ بیتی معادل نشانی آی‌پی یک ماشین باشد)

دو حالت ممکن است اتفاق بیفتد:

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

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

بازهم تکرار می‌کنیم، روشی که DNS برای ترجمه نشانی بکار می‌برد می‌تواند بدون اتصال (UDP) باشد که این کار به سرعت عمل ترجمه نشانی می‌افزاید.

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

پرس و جوی معکوس

[ویرایش]

فرض کنید حالتی به‌وجود بیاید که یک سرویس دهنده DNS، نشانی آی‌پی یک ماشین را بداند ولی نام نمادین معادل با آن را نداند. به عنوان مثال DNS مایل است بداند که چه نامی در شبکه اینترنت معادل با ۱۹۵٫۱۳٫۴۲٫۷ می‌باشد.

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

روش کار بدین صورت است که سرویس دهنده محلی یک تقاضا برای DNS متناظر با شبکه‌ای که مشخصه آن در نشانی آی‌پی، مشخص شده، ارسال می‌کند.

به‌عنوان مثال نشانی آی‌پی شبکه‌ای را ۱۳۸٫۱۴٫۷٫۱۳ در نظر بگیرید، نشانی کلاس B و مشخصه آن ۱۳۸٫۱۴٫۰٫۰ است. زمانی که مؤسسه‌ای یک کلاس نشانی آی‌پی ثبت می‌دهد یک سرویس دهنده DNS، متناظر با شبکه خود ایجاد کرده و آن را نیز معرفی می‌کند. سرویس دهنده محلی بایستی نشانی DNS متناظر با شبکه ۱۳۸٫۱۴٫۰٫۰ را پیدا کرده و سپس برای آن یک تقاضا ارسال کند. DNS مربوط به این شبکه، براساس زیر شبکه‌هایی که دارد، این سؤال را از طریق سرویس دهنده‌های متناظر با هر زیر شبکه پیگیری می‌کند. (چون هر زیر شبکه یک سرویس دهنده DNS مخصوص به خود دارد) نهایتاً یک نام نمادین حوزه معادل با آن نشانی آی‌پی برخواهد گشت.[۲۲][۲۳]

ساختار دامنه

[ویرایش]

نام دامنه از ارقام و حروفی تشکیل شده‌است. یکی قسمت نام کارساز است، دیگری نام دامنه و دیگری زیر دامنه است.[۲۴]

مثلاً http://www.google.com را در نظر بگیرید. http پروتکل انتقال اطلاعات در وب است. نشانه‌های //: جهت جداسازی پروتکل از دامنه استفاده می‌شود. //:http جزء سامانه نام دامنه قرار نمی‌گیرد. قسمت www نام زیر دامنه‌است.[۲۵] قسمت google نام دامنه و قسمت .com کارساز می‌باشد. هر زیردامنه می‌تواند آدرس IP متفاوتی با نام دامنه داشته باشد.

نام دامنه و زیر دامنه را صاحب دامنه انتخاب و ثبت می‌کند.

این قسمت‌ها شامل حروف و اعداد انگلیسی و علامت منفی (-) نیز می‌تواند در میان اعداد و حروف (و نُه در ابتدا و انتها) قرار گیرد.

کارسازهای مختلف، توسط آیکان (به انگلیسی: Icann) تصویب و در دسترس قرار می‌گیرد و شامل ۲ تا ۶ حرف انگلیسی می‌باشد.

ثبت دامنه در بسیاری از کارسازها نیاز به مجوزهای مخصوص دارد.

کارسازهای ۲ حرفی، در اختیار کشورهای صاحب آن‌ها قرار می‌گیرد و قوانین ثبت در این کارسازها، توسط حکومت‌ها تعیین می‌گردد.

مثلاً us در اختیار کشور آمریکا، .ir در اختیار کشور ایران و .fr در اختیار کشور فرانسه می‌باشد.

آیکان پروژه‌ای را در دست دارد تا ثبت نام‌های دامنه را به زبان‌های مختلف بین‌المللی امکان‌پذیر نماید. این پروژه هم‌اکنون در حالت آزمایش و بررسی قرار دارد.

جستارهای وابسته

[ویرایش]

یادداشت‌ها

[ویرایش]
  1. (به انگلیسی: Domain Name System (DNS))[۱]

منابع

[ویرایش]
  1. <klensin srch>, John C Klensin. "Role of the Domain Name System (DNS)". tools.ietf.org (به انگلیسی). Retrieved 2018-03-03.
  2. واژهٔ مصوب فرهنگستان زبان و ادب فارسی، دفتر نخست تا چهارم، ۱۳۷۶ تا ۸۵
  3. Mohammad (۲۰۲۲-۱۲-۲۴). «دانلود نرم افزار DNS Jumper». رفع ارور و خطای ویندوز - آموزش کاربردی - حل مشکلات بازی و نرم افزار. دریافت‌شده در ۲۰۲۲-۱۲-۲۹.
  4. Wu, Hao; Dang, Xrfianglei; Wang, Lidong; He, Longtao (2016). "Information fusion-based method for distributed domain name system cache poisoning attack detection and identification". IET Information Security (به انگلیسی). 10 (1): 37–44. doi:10.1049/iet-ifs.2014.0386. ISSN 1751-8717. S2CID 45091791.
  5. J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, September/October 2002, pp. 50–58" (PDF). Archived (PDF) from the original on 2015-04-17.
  6. Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
  7. Mockapetris, Paul (November 1987). Domain Names - Implementation and Specification. IETF. RFC 1035. https://tools.ietf.org/html/rfc1035.
  8. «DNS». reflects the structure of administrative. دریافت‌شده در ۲۰۲۴-۰۸-۲۷.
  9. Champika Wijayatunga (February 2015). "DNS Abuse Handling" (PDF). APNIC. Archived (PDF) from the original on 2015-12-22. Retrieved 18 December 2016.
  10. Nygren., E.; Sitaraman R. K.; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF). ACM SIGOPS Operating Systems Review. 44 (3): 2–19. doi:10.1145/1842733.1842736. S2CID 207181702. Archived (PDF) from the original on 2010-12-02. Retrieved November 19, 2012.
  11. Paul Mockapetris (November 1987). "How the database is divided into zones". Domain Names - Domain Concepts and Facilities. IETF. sec. 4.2. RFC 1034. https://tools.ietf.org/html/rfc1034#section-4.2. Retrieved 17 December 2015.
  12. Paul Mockapetris (November 1987). "Name space specifications and terminology". Domain Names - Domain Concepts and Facilities. IETF. sec. 3.1. RFC 1034. https://tools.ietf.org/html/rfc1034#section-3.1. Retrieved 17 December 2015.
  13. Shwake, Emily (2023-09-27). "What Is a Subdomain? Definition, Examples and Setup". Wix Blog (به انگلیسی). Retrieved 2024-01-09.
  14. Mockapetris, Paul (November 1987). Domain Names - Domain Concepts and Facilities. IETF. RFC 1034. https://tools.ietf.org/html/rfc1034.
  15. "Providers ignoring DNS TTL?". Slashdot. 2005. Retrieved 2012-04-07.
  16. Mockapetris, Paul (November 1987). Domain Names - Domain Concepts and Facilities. IETF. RFC 1034. https://tools.ietf.org/html/rfc1034.
  17. RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
  18. Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). "Oblivious DNS: Practical Privacy for DNS Queries" (PDF). Privacy Enhancing Technologies. 2019 (2): 228–244. arXiv:1806.00276. doi:10.2478/popets-2019-0028. S2CID 44126163. Archived (PDF) from the original on 2022-01-21.
  19. "Oblivious DNS Deployed by Cloudflare and Apple". 9 December 2020. Retrieved 27 July 2022.
  20. «What is DNS».
  21. Pauly, Tommy (2 September 2021). "Oblivious DNS Over HTTPS". IETF.
  22. Reverse lookup (۲۰۲۴-۰۲-۱۳). «دی ان اس گیمینگ». دریافت‌شده در ۲۰۲۴-۰۸-۲۷.
  23. Huston, Geoff (July 2019). "DNS Privacy and the IETF" (PDF). The Internet Protocol Journal. Archived (PDF) from the original on 2019-09-30.
  24. "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars". ICANN. 3 December 2015. Archived from the original on 22 December 2015. Retrieved 18 December 2015.
  25. "Find a Registrar". VeriSign, Inc. Retrieved 18 December 2015.

پیوند به بیرون

[ویرایش]