۱۲٫۶٪ جواب‌های DNS ایران امضای درست DNSSEC دارد.

این صفحه دقیقا چه چیزی را نشان می‌دهد؟

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

داده‌ها از Cloudflare Radar می‌آید، با مجوز CC BY-NC 4.0. Cloudflare یک شرکت بزرگ اینترنتی است و یکی از کارهایش سرویسی به اسم 1.1.1.1 است: جایی که دستگاه‌ها می‌توانند پرسش‌های DNS خود را به آن بفرستند (پایین‌تر می‌گوییم این پرسش‌ها چیست). Cloudflare بخشی عمومی به اسم Radar دارد که عددهای اینترنت کشورها را منتشر می‌کند. رادار سفید این عددها را فقط برای ایران می‌گیرد، ۳۰ روز نگه می‌دارد و بعد پاک می‌کند. عددهای این صفحه هر ۶ ساعت یک بار تازه می‌شوند.

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

وقتی صفحه‌ی DNS و DNSSEC در ایران را باز می‌کنید، به Cloudflare وصل نمی‌شوید. صفحه از روی نسخه‌ای ساخته می‌شود که رادار سفید پیش‌تر گرفته است. اگر یک بار Cloudflare در دسترس نباشد، صفحه این را می‌گوید: «دسترسی به کلادفلر به دلیل اختلال قطع است و ممکن است به خاطر قطعی اینترنت بین‌الملل باشد». آن وقت آخرین داده‌ای که داشته را نشان می‌دهد و درباره‌اش با زمان گذشته حرف می‌زند.

در این صفحه این چیزها را می‌بینید، همه برای ۷ روز گذشته:

1. نتیجه‌ی DNSSEC. از جواب‌ها، چند درصد امضاشده و درست (secure)، چند درصد بی‌امضا (insecure)، چند درصد با امضای خراب (invalid) و چند درصد هیچ‌کدام (other) بوده است.
2. دستگاه‌هایی که DNSSEC می‌فهمند. چند درصد پرسش‌ها از دستگاهی آمده که خودش امضا را هم خواسته است.
3. راه رسیدن پرسش. چند درصد با UDP، چند درصد با TCP، چند درصد با DNS over TLS و چند درصد با DNS over HTTPS آمده است.
4. IPv4 یا IPv6. پرسش با کدام نسخه‌ی آدرس اینترنت به 1.1.1.1 رسیده است.
5. نوع رکورد. بیشتر چه چیزی پرسیده شده: A، AAAA، HTTPS، TXT، MX، NS و بقیه.

عدد امروز هر کدام بالای همین صفحه است. این‌جا عدد نمی‌نویسیم، چون عددها عوض می‌شوند و متنی که عدد کهنه دارد، گمراه می‌کند.

DNS چیست؟ دفترچه‌ی تلفن اینترنت

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

اینترنت هم همین مشکل را دارد. هر کامپیوتری که سایتی روی آن است یک شماره دارد که به آن آدرس IP می‌گویند؛ چیزی شبیه پلاک خانه یا شماره‌ی تلفن. (درباره‌ی آدرس IP و دو نسخه‌اش، IPv4 و IPv6، در صفحه‌ی سهم IPv6 در اینترنت ایران مفصل نوشته‌ایم.) ولی هیچ‌کس شماره‌ها را حفظ نمی‌کند. ما اسم سایت را می‌نویسیم، مثلا example.com، و کسی باید بگوید این اسم به کدام شماره می‌رسد.

این کار را DNS می‌کند. DNS کوتاه‌شده‌ی Domain Name System است، یعنی «سامانه‌ی نام دامنه». دامنه همان اسم سایت است، مثل example.com. پس DNS دفترچه‌ی تلفن اینترنت است: اسم را می‌گیرد و شماره را پس می‌دهد. قاعده‌های اصلی‌اش در سال ۱۹۸۷ در دو سند به نام RFC 1034 و RFC 1035 نوشته شد. RFC یعنی سندی که قاعده‌های اینترنت در آن نوشته می‌شود و همه‌ی سازنده‌ها از روی آن کار می‌کنند.

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

فرض کنید در مرورگر نوشته‌اید example.com و Enter زده‌اید. پیش از آنکه حتی یک تکه از صفحه بیاید، این اتفاق‌ها می‌افتد:

1. مرورگر از دستگاه شما می‌پرسد: «شماره‌ی example.com چیست؟» اگر دستگاه کمی پیش همین را پرسیده باشد، جواب را در حافظه دارد و کار همین‌جا تمام است.
2. اگر نه، دستگاه پرسش را برای یک ریزالور (resolver) می‌فرستد. ریزالور یعنی «پیداکننده»: سرویسی که کارش پیدا کردن جواب از طرف شماست. 1.1.1.1 یک ریزالور است و ریزالور اپراتور اینترنت شما هم یکی دیگر.
3. ریزالور اگر جواب را در حافظه داشته باشد، فورا پس می‌دهد. اگر نه، راه می‌افتد و از بالای درخت می‌پرسد.
4. اول از سرورهای ریشه (root) می‌پرسد: «com را چه کسی می‌داند؟» ریشه آدرس سرورهای com را می‌دهد.
5. بعد از سرورهای com می‌پرسد: «example.com را چه کسی می‌داند؟» آن‌ها آدرس سرورهای خود example.com را می‌دهند.
6. آخر از همه، از سرورهای خود example.com می‌پرسد و جواب نهایی را می‌گیرد.
7. ریزالور جواب را به دستگاه شما می‌دهد و یک نسخه هم برای مدتی نگه می‌دارد تا پرسش بعدی سریع‌تر جواب بگیرد.

همه‌ی این رفت و برگشت معمولا در کسری از ثانیه تمام می‌شود. ولی هر بار که لازم باشد، پیش از باز شدن صفحه، این زمان هم به انتظار شما اضافه می‌شود.

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

در DNS دو نقش هست که بهتر است از هم جدا کنید:

• ریزالور کسی است که می‌پرسد. خودش صاحب هیچ اسمی نیست؛ فقط از طرف دستگاه‌ها می‌گردد و جواب‌ها را برای مدتی نگه می‌دارد. 1.1.1.1 از این نوع است.
• سرور معتبر (authoritative server) کسی است که می‌داند. سروری است که صاحب دامنه رکوردهای دامنه‌اش را روی آن گذاشته و حرف آخر را درباره‌ی آن دامنه می‌زند. «معتبر» یعنی جوابش از دست اول است، نه از حافظه‌ی کس دیگر.

با مثال دفترچه: سرور معتبر خود صاحب خانه است که شماره‌ی خودش را می‌داند. ریزالور منشی‌ای است که برای شما زنگ می‌زند، می‌پرسد و شماره را در دفترش یادداشت می‌کند تا دفعه‌ی بعد دوباره نپرسد.

این یادداشت‌ها چقدر می‌ماند؟ TTL

هر رکورد DNS یک عدد کنار خودش دارد به اسم TTL (Time To Live، یعنی «مدت زنده بودن»). این عدد به ریزالور می‌گوید جواب را چند ثانیه نگه دارد و بعد دوباره بپرسد. TTL کوتاه یعنی تغییرهای شما زودتر به همه می‌رسد، ولی ریزالورها بیشتر می‌پرسند. TTL بلند یعنی پرسش کمتر و جواب سریع‌تر، ولی اگر آدرس سایت را عوض کنید، بعضی‌ها تا مدتی آدرس قدیمی را می‌بینند. برای همین مدیرهای سایت پیش از جابه‌جا کردن سرور، TTL را چند روز زودتر کوتاه می‌کنند.

انواع رکورد DNS: هر خط دفترچه برای یک کار

دفترچه‌ی تلفن فقط شماره نداشت؛ گاهی آدرس، شماره‌ی فکس یا اسم کسی که جای صاحب خانه جواب می‌دهد هم کنار اسم بود. DNS هم همین‌طور است. کنار هر دامنه چند نوع رکورد (record، یعنی خط نوشته) هست و هر نوع برای یک کار است. صفحه‌ی رادار سفید نشان می‌دهد پرسش‌ها بیشتر درباره‌ی کدام نوع است. این‌ها مهم‌ترین‌هایند.

رکورد A: شماره‌ی IPv4

رکورد A رایج‌ترین رکورد است. A از Address یعنی «آدرس» آمده. این رکورد می‌گوید این دامنه به کدام آدرس IPv4 می‌رسد. IPv4 نسخه‌ی قدیمی آدرس اینترنت است، چهار عدد که با نقطه از هم جدا شده‌اند. وقتی مرورگر می‌خواهد سایتی را باز کند، تقریبا همیشه رکورد A را می‌پرسد.

رکورد AAAA: شماره‌ی IPv6

رکورد AAAA (چهار A) همان کار را برای IPv6 می‌کند، نسخه‌ی تازه و خیلی بلندتر آدرس اینترنت. اسمش این است چون آدرس IPv6 چهار برابر آدرس IPv4 جا می‌گیرد. قاعده‌اش در RFC 3596 آمده. دستگاهی که IPv6 دارد معمولا هم A و هم AAAA را می‌پرسد و هر کدام زودتر جواب داد، با آن وصل می‌شود. برای همین در نمودار نوع رکوردها، AAAA کنار A دیده می‌شود.

اگر سایتی دارید و می‌خواهید روی IPv6 هم در دسترس باشد، باید رکورد AAAA داشته باشد. بدون آن، دستگاه‌ها حتی اگر IPv6 داشته باشند، با IPv4 سراغ سایتتان می‌آیند.

رکورد CNAME: «به جای من از فلانی بپرس»

رکورد CNAME (Canonical Name، یعنی «نام اصلی») شماره نمی‌دهد؛ می‌گوید این اسم، اسم دیگری برای فلان دامنه است. مثلا www.example.com می‌تواند CNAME به example.com باشد. ریزالور وقتی به CNAME می‌رسد، می‌رود و اسم دوم را می‌پرسد.

دو نکته درباره‌ی رکورد CNAME که بیشتر مدیرهای دامنه دیر می‌فهمند:

• اسمی که CNAME دارد نمی‌تواند رکورد دیگری کنارش داشته باشد. این قاعده در خود RFC 1034 آمده است.
• برای همین، خود دامنه‌ی اصلی (example.com بدون هیچ پیشوندی) نمی‌تواند CNAME باشد، چون همیشه رکوردهای دیگری مثل NS لازم دارد.

رکورد MX: نامه‌ها را کجا بفرستیم

رکورد MX (Mail Exchanger، یعنی «تحویل‌گیرنده‌ی نامه») می‌گوید ایمیل‌های این دامنه را به کدام سرور تحویل بدهند. وقتی کسی به آدرسی در example.com ایمیل می‌زند، سرور ایمیل فرستنده رکورد MX را می‌پرسد. هر MX یک عدد اولویت دارد؛ عدد کوچک‌تر یعنی اول سراغ این برو. این روش در RFC 5321 که قاعده‌ی تحویل ایمیل است توضیح داده شده.

رکورد TXT: یادداشت آزاد

رکورد TXT (Text، یعنی «متن») یک خط متن آزاد است. اول برای یادداشت ساخته شد، ولی امروز کار مهم‌تری دارد:

• ثابت کردن مالکیت. خیلی از سرویس‌ها، مثل Google Search Console، برای اینکه مطمئن شوند دامنه مال شماست، می‌گویند یک متن مشخص را در TXT بگذارید (راهنمای Google).
• ایمیل. رکورد SPF که می‌گوید کدام سرورها حق دارند از طرف دامنه‌ی شما ایمیل بفرستند، در TXT نوشته می‌شود (RFC 7208). این کمک می‌کند ایمیل‌های شما به پوشه‌ی هرزنامه نروند.

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

رکورد NS (Name Server، یعنی «سرور نام») می‌گوید سرورهای معتبر این دامنه کدام‌اند. همان قدم پنجم بالا: وقتی سرورهای com می‌گویند «example.com را از فلان سرور بپرس»، این را با رکورد NS می‌گویند. وقتی دامنه‌ای می‌خرید و سرورهای DNS آن را در پنل فروشنده‌ی دامنه عوض می‌کنید، دارید NS را عوض می‌کنید.

رکورد PTR: از شماره به اسم

رکورد PTR (Pointer، یعنی «اشاره‌گر») برعکس بقیه کار می‌کند: شماره را می‌گیرد و اسم را پس می‌دهد. به این کار جستجوی معکوس (reverse lookup) می‌گویند. مثل این است که شماره‌ای روی گوشی‌تان افتاده و بخواهید بدانید مال کیست. این رکوردها زیر دو شاخه‌ی ویژه نگه داشته می‌شوند: in-addr.arpa برای IPv4 و ip6.arpa برای IPv6.

PTR بیشتر به کار سرورهای ایمیل می‌آید. خیلی از سرورهای ایمیل نامه‌ای را که از آدرسی بی‌اسم آمده، با شک نگاه می‌کنند. صاحب PTR هم معمولا صاحب آدرس IP است، نه صاحب دامنه؛ یعنی برای تنظیمش باید سراغ کسی رفت که سرور را به شما داده.

رکورد HTTPS و SVCB: راه رسیدن را از پیش بگو

رکورد HTTPS تازه‌ترین رکورد این فهرست است و در سال ۲۰۲۳ در RFC 9460 نوشته شد. خانواده‌اش SVCB نام دارد (Service Binding، یعنی «پیوند به سرویس») و HTTPS نسخه‌ی ویژه‌ی وب آن است.

برای اینکه بفهمید چرا مهم است، اول باید مشکل را ببینید. مرورگر با رکورد A فقط شماره را می‌گیرد. نمی‌داند آن سرور چه زبان‌هایی بلد است. مثلا نمی‌داند HTTP/3 را پشتیبانی می‌کند یا نه. HTTP زبانی است که مرورگر و سایت با آن حرف می‌زنند و HTTP/3 تازه‌ترین نسخه‌ی آن است که روی راه تازه‌ای به اسم QUIC کار می‌کند. (درباره‌ی نسخه‌های HTTP در صفحه‌ی HTTPS و HTTP/3 در ایران نوشته‌ایم.)

بدون رکورد HTTPS، ماجرا معمولا این‌طور است:

1. مرورگر با نسخه‌ی قدیمی‌تر وصل می‌شود.
2. سایت در جوابش می‌گوید «راستی، من HTTP/3 هم بلدم». این پیام را Alt-Svc می‌گویند و در RFC 7838 آمده.
3. مرورگر این را یادش می‌ماند و دفعه‌ی بعد با HTTP/3 می‌آید.

یعنی اولین بار، فرصت HTTP/3 از دست می‌رود. رکورد HTTPS این را درست می‌کند: سایت از همان اول، در خود DNS، می‌گوید «من HTTP/3 بلدم». در این رکورد چیزی به اسم alpn هست که فهرست زبان‌های سرور است و اگر h3 در آن باشد، یعنی HTTP/3. مرورگری که رکورد HTTPS را می‌پرسد، می‌تواند از اولین بار با HTTP/3 بیاید. Cloudflare در نوشته‌ای درباره‌ی همین رکورد این را با جزئیات توضیح داده است.

رکورد HTTPS چیزهای دیگری هم می‌تواند بگوید، مثل آدرس‌های IPv4 و IPv6 پیشنهادی (ipv4hint و ipv6hint) تا مرورگر زودتر راه بیفتد. چیز جالب‌تر اینکه این رکورد، برخلاف CNAME، روی خود دامنه‌ی اصلی هم مجاز است.

برای همین است که در نمودار رادار سفید رکورد HTTPS را کنار A و AAAA می‌بینید: هر بار مرورگری که این رکورد را می‌شناسد سایتی را باز می‌کند، آن را هم می‌پرسد، حتی اگر سایت چنین رکوردی نداشته باشد.

DNSSEC چیست؟ مهر و امضای روی دفترچه‌ی تلفن

حالا به سوال مهم‌تری برسیم. از کجا بدانیم جوابی که ریزالور داده درست است؟

DNS قدیمی هیچ راهی برای این نداشت. جواب می‌آمد و دستگاه قبولش می‌کرد. اگر کسی در راه، جوابی ساختگی جای جواب اصلی می‌گذاشت، دستگاه نمی‌فهمید. مثل این است که کسی یک برگ دفترچه‌ی تلفن را عوض کند و شماره‌ی خودش را جای شماره‌ی بانک بنویسد. به این حمله مسموم کردن حافظه‌ی DNS (cache poisoning) می‌گویند.

DNSSEC (DNS Security Extensions، یعنی «افزونه‌های امنیتی DNS») برای همین ساخته شد. قاعده‌هایش در سه سند آمده: RFC 4033، RFC 4034 و RFC 4035. ایده‌اش ساده است: صاحب هر دامنه کنار رکوردهایش یک امضای دیجیتال می‌گذارد. ریزالور امضا را بررسی می‌کند و اگر درست نبود، جواب را دور می‌اندازد.

با مثال دفترچه: DNSSEC مثل این است که کنار هر شماره، مهر صاحب آن شماره خورده باشد. هر کس برگ را عوض کند، نمی‌تواند همان مهر را بزند.

امضای دیجیتال یعنی چه؟

امضای دیجیتال با یک جفت کلید کار می‌کند. کلید این‌جا یعنی یک عدد خیلی بلند:

• کلید خصوصی فقط دست صاحب دامنه است و با آن امضا می‌کند.
• کلید عمومی را همه می‌توانند ببینند و با آن امضا را بررسی کنند.

کسی که فقط کلید عمومی را دارد، می‌تواند بفهمد امضا درست است یا نه، ولی نمی‌تواند امضای تازه بسازد. برای همین جعل امضا ممکن نیست.

زنجیره‌ی اعتماد: هر کس امضای پایینی را تایید می‌کند

یک سوال می‌ماند: از کجا بدانیم کلید عمومی example.com خودش درست است؟ اگر کسی کلید را هم عوض کرده باشد؟

جواب DNSSEC یک زنجیره‌ی اعتماد است، درست به همان شکل درختی که در قدم‌های بالا دیدیم:

1. ریشه‌ی DNS کلید خودش را دارد و همه‌ی ریزالورها این کلید را از پیش می‌شناسند. ریشه در سال ۲۰۱۰ امضا شد (Wikipedia).
2. ریشه با کلیدش، اثر انگشت کلید com را امضا می‌کند.
3. com با کلیدش، اثر انگشت کلید example.com را امضا می‌کند.
4. example.com با کلیدش، رکوردهای خودش را امضا می‌کند.

به آن اثر انگشت که پدر برای فرزند نگه می‌دارد رکورد DS (Delegation Signer، یعنی «امضاکننده‌ی واگذاری») می‌گویند. کلید عمومی خود دامنه در رکوردی به اسم DNSKEY و امضای هر دسته رکورد در رکوردی به اسم RRSIG است. لازم نیست این اسم‌ها را حفظ کنید؛ فقط بدانید هر حلقه حلقه‌ی پایینی را تایید می‌کند و اگر یکی بشکند، کل زنجیر برای آن دامنه می‌شکند.

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

DNSSEC را با رمزگذاری اشتباه نگیرید. DNSSEC جواب را امضا می‌کند، نه پنهان. هر کس در راه باشد، هنوز می‌تواند ببیند شما چه اسمی پرسیده‌اید و چه جوابی گرفته‌اید؛ فقط نمی‌تواند جواب را عوض کند بی‌آنکه لو برود. برای پنهان کردن پرسش، راه دیگری لازم است که پایین‌تر به آن می‌رسیم: DNS رمزدار.

secure، insecure و invalid یعنی چه؟

در صفحه‌ی رادار سفید، جواب‌ها در چهار دسته آمده‌اند. Cloudflare این دسته‌ها را برای جواب‌هایی گزارش می‌کند که 1.1.1.1 داده است. 1.1.1.1 امضاها را خودش بررسی می‌کند (مستندات 1.1.1.1). معنای هر دسته، نزدیک به همان چیزی است که در RFC 4035 آمده:

• secure (امضاشده و درست). زنجیره‌ی امضا از ریشه تا خود رکورد کامل بود و همه‌ی امضاها درست بودند. این جواب با اطمینان دست‌نخورده است.
• insecure (بی‌امضا). دامنه اصلا DNSSEC ندارد. زنجیر در جایی تمام شده و پدر گفته «این فرزند امضا ندارد». جواب احتمالا درست است، ولی راهی برای اثباتش نیست. این خطا نیست؛ وضع عادی بیشتر دامنه‌های دنیاست.
• invalid (نامعتبر). امضا باید می‌بود ولی درست نبود: یا خراب بود، یا تاریخش گذشته بود، یا با کلید جور نبود. ریزالوری که امضا را بررسی می‌کند، چنین جوابی را پس نمی‌دهد و به جایش خطا می‌دهد. در RFC 4035 به این حالت bogus یعنی «قلابی» می‌گویند.
• other (بقیه). جواب‌هایی که در هیچ‌کدام از سه دسته‌ی بالا نمی‌گنجند.

یک نکته‌ی مهم درباره‌ی invalid: در عمل، بیشتر جواب‌های نامعتبر نتیجه‌ی حمله نیستند؛ نتیجه‌ی اشتباه در تنظیم هستند. مثلا صاحب دامنه کلیدش را عوض کرده ولی رکورد DS را در پدر به‌روز نکرده، یا امضاها را دیر تازه کرده و تاریخشان گذشته است. نتیجه برای بازدیدکننده یکی است: سایت برای کسانی که ریزالورشان امضا را بررسی می‌کند، باز نمی‌شود. پس اگر DNSSEC را روشن می‌کنید، با دقت روشنش کنید.

عدد secure یعنی چه و چه چیزی را نمی‌گوید؟

عدد secure در رادار سفید یعنی از جواب‌هایی که 1.1.1.1 در این ۷ روز به پرسش‌های ایران داده، چند درصد امضای درست داشته است. چند نکته برای خواندن درستش:

• سهم پرسش‌هاست، نه سهم دامنه‌ها. اگر یک دامنه‌ی امضاشده خیلی پرطرفدار باشد، سهم secure را بالا می‌برد، هرچند فقط یک دامنه است.
• فقط پرسش‌های 1.1.1.1 است. ریزالورهای دیگر ممکن است عدد دیگری ببینند.
• درباره‌ی دامنه‌های ir. به‌تنهایی نیست. پرسش‌های ایران درباره‌ی هر دامنه‌ای در دنیاست، نه فقط دامنه‌های ایرانی.

دستگاه‌هایی که DNSSEC را می‌فهمند

عدد دوم این بخش، سهم دستگاه‌هایی است که DNSSEC را «می‌فهمند» (DNSSEC-aware). یعنی چه؟

وقتی دستگاهی پرسش DNS می‌فرستد، می‌تواند در پرسشش یک پرچم کوچک بگذارد که می‌گوید «امضاها را هم برایم بفرست». به این پرچم DO می‌گویند (DNSSEC OK، یعنی «DNSSEC برایم اشکالی ندارد»). قاعده‌اش در RFC 3225 آمده. دستگاهی که این پرچم را می‌گذارد، نشان می‌دهد امضا برایش معنی دارد و شاید خودش هم بررسی‌اش کند.

حالا فرق این عدد با عدد secure را ببینید:

• عدد secure درباره‌ی دامنه‌هاست: چند درصد جواب‌ها امضا داشته‌اند.
• عدد DNSSEC-aware درباره‌ی دستگاه‌هاست: چند درصد پرسش‌ها از دستگاهی آمده که امضا را خواسته.

اگر دستگاهی پرچم DO را نگذارد، باز هم از DNSSEC سود می‌برد، به شرطی که ریزالورش امضا را بررسی کند. 1.1.1.1 این کار را برای همه می‌کند و جواب نامعتبر را به هیچ‌کس نمی‌دهد. ولی دستگاهی که خودش امضا را بررسی می‌کند، به ریزالور هم کاملا تکیه نمی‌کند. بیشتر گوشی‌ها و کامپیوترهای معمولی خودشان امضا را بررسی نمی‌کنند و این را به ریزالور می‌سپارند؛ برای همین عجیب نیست اگر این عدد پایین باشد.

DNSSEC را چطور برای دامنه‌ی خودم روشن کنم؟

اگر مدیر دامنه هستید و سوالتان این است که «DNSSEC ارزش روشن کردن دارد؟»، اول بدانید چه چیزی به دست می‌آورید: هیچ‌کس در راه نمی‌تواند جواب‌های DNS دامنه‌ی شما را عوض کند بی‌آنکه ریزالورهای بررسی‌کننده بفهمند. در عوض، یک کار نگه‌داری هم به کارهایتان اضافه می‌شود.

مراحل کلی، هر جا که DNS شما باشد، تقریبا همین است:

1. امضا کردن در جای DNS. جایی که رکوردهای دامنه‌تان را نگه می‌دارد (سرور معتبر) باید DNSSEC را برای دامنه روشن کند. با این کار کلیدها ساخته می‌شوند و رکوردها امضا می‌شوند. بیشتر سرویس‌های DNS این را با یک گزینه انجام می‌دهند و امضاها را هم خودشان تازه نگه می‌دارند.
2. گرفتن رکورد DS. بعد از روشن شدن، همان‌جا یک رکورد DS به شما نشان داده می‌شود؛ همان اثر انگشت کلید. معمولا چند عدد است: شماره‌ی کلید (key tag)، شماره‌ی الگوریتم، نوع اثر انگشت و خود اثر انگشت.
3. گذاشتن DS نزد ثبت‌کننده‌ی دامنه. این مهم‌ترین قدم است. ثبت‌کننده (registrar) جایی است که دامنه را از آن خریده‌اید و دامنه را نزد پدرش (مثلا com یا ir) ثبت کرده است. رکورد DS را در پنل ثبت‌کننده وارد می‌کنید تا به پدر برسد. تا وقتی این قدم انجام نشده، زنجیره کامل نیست و جواب‌های شما insecure حساب می‌شوند.
4. صبر و بررسی. چند ساعت تا یک روز طول می‌کشد تا DS در پدر منتشر شود و حافظه‌های قدیمی خالی شوند. بعد بررسی کنید که زنجیره کامل است.

بعضی سرویس‌های DNS و ثبت‌کننده‌ها قدم سوم را خودکار انجام می‌دهند. برای این کار قاعده‌ای در RFC 7344 و RFC 8078 نوشته شده که به آن CDS و CDNSKEY می‌گویند: فرزند خودش اثر انگشت تازه را منتشر می‌کند و پدر برش می‌دارد. اگر جای DNS و ثبت‌کننده‌ی شما این را پشتیبانی کنند، کار شما کمتر است.

dnssec check: از کجا بفهمم درست کار می‌کند؟

بعد از روشن کردن DNSSEC، بررسی‌اش را جدی بگیرید:

• با ابزار خط فرمان. ابزاری به اسم dig که روی بیشتر سیستم‌های لینوکس و مک هست، با گزینه‌ی +dnssec امضاها را هم نشان می‌دهد. اگر ریزالوری که از آن می‌پرسید امضا را بررسی کند، در جواب پرچم ad (Authenticated Data، یعنی «داده‌ی تاییدشده») را می‌بینید. این پرچم یعنی ریزالور زنجیره را تا ریشه بررسی کرده و درست بوده.
• با ابزارهای آنلاین. چند ابزار رایگان آنلاین هست که اسم دامنه را می‌گیرند و زنجیره را حلقه به حلقه نقاشی می‌کنند. اگر حلقه‌ای قرمز بود، همان‌جا مشکل است.

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

بیشتر مشکل‌های DNSSEC از این سه جا می‌آید:

1. عوض کردن جای DNS بدون برداشتن DS. اگر دامنه را به سرور DNS دیگری ببرید و DS قدیمی نزد ثبت‌کننده بماند، امضاهای تازه با اثر انگشت قدیمی جور نیستند و همه‌ی جواب‌ها invalid می‌شوند. اول DNSSEC را در جای قدیمی خاموش کنید و DS را بردارید، صبر کنید، بعد جابه‌جا شوید و دوباره روشن کنید.
2. تاریخ گذشتن امضاها. هر امضا تاریخ انقضا دارد. اگر سرور امضاها را خودکار تازه نکند، روزی همه‌شان کهنه می‌شوند.
3. عوض کردن کلید بی‌برنامه. اگر کلید را عوض کنید و DS در پدر هنوز قدیمی باشد، زنجیر می‌شکند. کلید را مرحله به مرحله عوض کنید و بگذارید مدتی هر دو کلید کنار هم باشند.

DNS رمزدار: پاکت دربسته

گفتیم DNSSEC جواب را امضا می‌کند ولی پنهان نمی‌کند. DNS قدیمی مثل کارت‌پستال است: هر کس در راه دستش به آن برسد، می‌تواند بخواند چه اسمی پرسیده‌اید. این پرسش‌ها با UDP روی درگاه ۵۳ فرستاده می‌شوند. UDP یعنی روشی برای فرستادن بسته‌های کوچک بدون سلام و احوالپرسی؛ سریع است، ولی هیچ پوششی ندارد.

برای اینکه پرسش‌ها مثل نامه در پاکت دربسته بروند، دو راه ساخته شد.

DNS over TLS (DoT): پاکت مخصوص DNS

DNS over TLS که کوتاهش می‌کنند DoT، پرسش DNS را در یک کانال TLS می‌فرستد. TLS همان رمزگذاری است که قفل کنار نشانی سایت‌ها را می‌سازد. (درباره‌ی نسخه‌های TLS در صفحه‌ی نسخه‌ی TLS در ایران نوشته‌ایم.) قاعده‌اش در سال ۲۰۱۶ در RFC 7858 آمد.

DoT درگاه مخصوص خودش را دارد: درگاه ۸۵۳. درگاه (port) یعنی شماره‌ی در؛ هر سرور چند در دارد و هر سرویس پشت یکی از آن‌ها گوش می‌دهد. چون DoT در جدای خودش را دارد، شبکه می‌بیند که این پرسش DNS است، ولی نمی‌تواند بخواند چه چیزی پرسیده شده.

DNS over HTTPS (DoH): پاکت DNS لای نامه‌های وب

DNS over HTTPS که کوتاهش می‌کنند DoH، پرسش DNS را مثل یک درخواست معمولی وب، با HTTPS می‌فرستد. قاعده‌اش در سال ۲۰۱۸ در RFC 8484 آمد. DoH از همان درگاه ۴۴۳ استفاده می‌کند که همه‌ی سایت‌های HTTPS از آن استفاده می‌کنند.

فرقش با DoT در همین است: پرسش DoH از بیرون شبیه هر درخواست دیگر وب است. یعنی پاکت DNS لای بقیه‌ی نامه‌های وب می‌رود. برای همین بیشتر مرورگرها DoH را برای DNS رمزدار برگزیده‌اند؛ می‌توانند خودشان پرسش را بفرستند و منتظر تنظیم سیستم‌عامل نمانند.

UDP، TCP، DoT و DoH در صفحه‌ی رادار سفید

در صفحه، پرسش‌های ایران به 1.1.1.1 در چهار دسته‌ی راه رسیدن آمده‌اند:

• UDP. کارت‌پستال قدیمی. سریع و بی‌پوشش. بیشتر پرسش‌های DNS دنیا هنوز همین‌طور است.
• TCP. باز هم بی‌پوشش، ولی با سلام و احوالپرسی و برای جواب‌های بزرگ. وقتی جوابی در یک بسته‌ی UDP جا نمی‌شود، مثلا چون امضاهای DNSSEC بزرگش کرده‌اند، ریزالور و دستگاه با TCP دوباره می‌پرسند (RFC 7766). TCP یعنی روشی که پیش از فرستادن، اتصال برقرار می‌کند و مطمئن می‌شود همه‌ی تکه‌ها رسیده.
• DoT. پاکت دربسته، روی در مخصوص ۸۵۳.
• DoH. پاکت دربسته، لای نامه‌های وب روی در ۴۴۳.

سهم DoT و DoH با هم، تقریبا سهم پرسش‌هایی است که در راه خوانده نمی‌شوند. عدد امروز بالای همین صفحه است.

DNS رمزدار با DNSSEC چه فرقی دارد؟

این دو جای هم را نمی‌گیرند؛ دو کار متفاوت می‌کنند:

• DNS رمزدار (DoT و DoH) راه بین دستگاه شما و ریزالور را می‌پوشاند. کسی در این مسیر نمی‌تواند پرسش را بخواند یا عوض کند. ولی اگر خود ریزالور جواب اشتباه بدهد، این پاکت کمکی نمی‌کند.
• DNSSEC خود جواب را امضا می‌کند، از صاحب دامنه تا هر کجا که برود. ولی پرسش را پنهان نمی‌کند.

با مثال پست: DNS رمزدار پاکت دربسته است؛ DNSSEC مهر فرستنده روی نامه. بهترین حالت، نامه‌ی مهرشده در پاکت دربسته است.

DNS ipv6: پرسش‌هایی که روی IPv6 می‌آیند

نمودار IPv4 و IPv6 این صفحه نشان می‌دهد پرسش‌ها با کدام نسخه‌ی آدرس اینترنت به 1.1.1.1 رسیده‌اند. این را با رکورد AAAA قاطی نکنید:

• پرسش روی IPv6 یعنی خود پرسش از راه IPv6 به ریزالور رسیده. یعنی دستگاه یا شبکه‌ی پرسنده IPv6 داشته و ریزالور را با آدرس IPv6 آن صدا زده.
• پرسش AAAA یعنی دستگاه آدرس IPv6 یک سایت را پرسیده، از هر راهی که پرسیده باشد.

دستگاهی می‌تواند روی IPv4 پرسش AAAA بفرستد، یا روی IPv6 پرسش A. پس این دو عدد به هم مربوط‌اند ولی یکی نیستند. سهم پرسش‌های DNS روی IPv6 معمولا به سهم IPv6 اتصال‌ها نزدیک است، چون دستگاهی که IPv6 دارد، اغلب ریزالورش را هم با IPv6 صدا می‌زند. برای سهم IPv6 کل درخواست‌های ایران، صفحه‌ی سهم IPv6 در اینترنت ایران را ببینید.

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

عددهای این صفحه برای این است که تصویری از وضع امروز داشته باشید، نه اینکه دستوری بدهد. با این حال، چند سوال رایج هست که این عددها کمی روشنشان می‌کنند:

• AAAA بگذارم؟ اگر سرورتان IPv6 دارد، بله؛ هزینه‌ای ندارد و دستگاه‌های IPv6دار مستقیم می‌رسند. نمودار نوع رکورد نشان می‌دهد AAAA چقدر پرسیده می‌شود.
• رکورد HTTPS بگذارم؟ اگر سایتتان HTTP/3 دارد و جای DNS شما این رکورد را پشتیبانی می‌کند، با آن مرورگرهای آشنا با این رکورد از همان بار اول با HTTP/3 می‌آیند. اینکه HTTPS در نمودار چقدر پرسیده می‌شود، نشان می‌دهد چه سهمی از دستگاه‌ها دنبالش هستند.
• DNSSEC روشن کنم؟ این تصمیم شماست. عدد secure نشان می‌دهد چه سهمی از جواب‌ها امروز امضا دارند؛ عدد invalid نشان می‌دهد اشتباه در تنظیم چقدر پیش می‌آید. اگر روشنش می‌کنید، بخش «سه اشتباه رایج» بالا را دوباره بخوانید.
• TTL را چند بگذارم؟ جواب یکسانی ندارد. برای رکوردهایی که کم عوض می‌شوند، TTL بلندتر پرسش کمتر و سرعت بیشتر یعنی؛ پیش از جابه‌جایی، کوتاهش کنید.

این عددها چه چیزی را نمی‌گویند؟

برای اینکه این صفحه را درست بخوانید، این‌ها را هم بدانید:

• همه‌ی DNS ایران نیست. فقط پرسش‌هایی است که به 1.1.1.1 رسیده. ریزالورهای اپراتورها و بقیه‌ی ریزالورها در این عدد نیستند.
• سهم پرسش‌هاست، نه آدم‌ها یا دامنه‌ها. یک دستگاه یا یک برنامه که پشت سر هم می‌پرسد، سهم بیشتری می‌گیرد.
• نرخ خطا نشان داده نمی‌شود. Cloudflare نرخ جواب‌های خطا را هم منتشر می‌کند، ولی این صفحه آن را نشان نمی‌دهد. دلیل خطای یک پرسش می‌تواند خیلی چیزها باشد و یک عدد تنها، بیشتر گیج می‌کند تا کمک.
• عدد هر هفته عوض می‌شود. بازه‌ی ۷ روزه یعنی یک روز شلوغ یا آرام کل عدد را عوض نمی‌کند، ولی عدد ثابت هم نیست.
• کار Cloudflare نیست. رادار سفید را Cloudflare نساخته و تایید نکرده؛ فقط داده‌های عمومی‌اش را با مجوز CC BY-NC 4.0 به کار برده است.

چند پرسش کوتاه

dns چیست به زبان ساده، در یک جمله؟

DNS دفترچه‌ی تلفن اینترنت است: اسم سایت را می‌گیرد و آدرس IP آن را پس می‌دهد تا دستگاه شما بداند به کجا وصل شود.

رکورد dns چیست؟

هر خط از دفترچه‌ی DNS یک رکورد است. هر رکورد یک نوع دارد (A، AAAA، CNAME، MX، TXT، NS، PTR، HTTPS و بقیه) و هر نوع یک چیز درباره‌ی دامنه می‌گوید: آدرسش، اسم دیگرش، سرور ایمیلش، سرورهای DNSش یا راه رسیدن به آن.

رکورد cname با رکورد A چه فرقی دارد؟

رکورد A مستقیم آدرس IPv4 را می‌دهد. رکورد CNAME آدرس نمی‌دهد؛ می‌گوید «این اسم، اسم دیگری است برای فلان دامنه، برو آن را بپرس».

dnssec چیست، در یک جمله؟

DNSSEC امضای دیجیتال روی جواب‌های DNS است تا کسی در راه نتواند جواب را عوض کند بی‌آنکه لو برود.

DNSSEC سایتم را کند می‌کند؟

جواب‌های امضاشده کمی بزرگ‌ترند و ریزالور باید امضا را بررسی کند، ولی ریزالورها جواب‌ها را نگه می‌دارند و بیشتر پرسش‌ها از حافظه جواب می‌گیرند. بزرگ‌تر شدن جواب گاهی باعث می‌شود پرسش با TCP تکرار شود.

dns over https (doh) با dot dns over tls چه فرقی دارد؟

هر دو پرسش DNS را رمزدار می‌فرستند. DoT در مخصوص خودش (۸۵۳) را دارد؛ DoH لای ترافیک معمولی وب روی در ۴۴۳ می‌رود.

چرا رکورد HTTPS این‌قدر پرسیده می‌شود؟

چون مرورگرهایی که این رکورد را می‌شناسند، برای هر سایتی که باز می‌کنند آن را هم می‌پرسند تا بدانند از همان اول با HTTP/3 بیایند یا نه؛ چه سایت چنین رکوردی داشته باشد، چه نداشته باشد.

این صفحه کی تازه می‌شود؟

عددهای DNS هر ۶ ساعت یک بار از Cloudflare Radar گرفته می‌شوند و ۳۰ روز نگه داشته می‌شوند.

خلاصه در چند خط

• DNS دفترچه‌ی تلفن اینترنت است. ریزالور از طرف شما می‌پرسد؛ سرور معتبر جواب دست اول را دارد.
• هر رکورد برای یک کار است: A و AAAA آدرس، CNAME اسم دیگر، MX ایمیل، TXT یادداشت و تایید، NS سرورهای DNS، PTR جستجوی معکوس، و HTTPS راه رسیدن، از جمله HTTP/3 (RFC 9460).
• DNSSEC امضای روی جواب است (RFC 4033 تا ۴۰۳۵). secure یعنی امضای درست، insecure یعنی بی‌امضا، invalid یعنی امضای خراب که معمولا از اشتباه در تنظیم است.
• برای روشن کردن DNSSEC، دامنه را در جای DNS امضا کنید و رکورد DS را نزد ثبت‌کننده‌ی دامنه بگذارید.
• DoT (RFC 7858) و DoH (RFC 8484) پرسش را در پاکت دربسته می‌برند؛ DNSSEC مهر روی نامه است. این دو کنار هم کار می‌کنند.
• همه‌ی عددهای این صفحه فقط از پرسش‌های ایران به 1.1.1.1 در ۷ روز گذشته است، نه همه‌ی DNS ایران.

برای دیدن عددهای امروز، به صفحه‌ی DNS و DNSSEC در ایران بروید و برای بقیه‌ی عددهای اینترنت ایران، صفحه‌ی اصلی رادار سفید را ببینید. داده‌ها از Cloudflare Radar می‌آید، با مجوز CC BY-NC 4.0.