معالجة نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS)
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
مقدمة
يتم إرسال طلبات البحث والردود التقليدية لنظام أسماء النطاقات عبر بروتوكول UDP أو بروتوكول TCP بدون تشفير.
هذه الحسابات عرضة للتنصت والانتحال
(بما في ذلك فلترة الإنترنت المستندة إلى نظام أسماء النطاقات).
تكون الردود التي ترسِلها برامج التعيين المتكرر إلى العملاء أكثر عرضة
للتغييرات غير المرغوب فيها أو الضارة، في حين أن الاتصالات بين برامج التعيين المتكرر
وخوادم الأسماء الموثوقة غالبًا ما تتضمن
حماية إضافية.
لمعالجة هذه المشاكل، يقدّم "نظام أسماء النطاقات العام من Google" التحويل باستخدام نظام أسماء النطاقات عبر اتصالات بروتوكول التحكم بالنقل المشفّرة باستخدام بروتوكول أمان طبقة النقل (TLS)، كما هو محدَّد في RFC 7858.
يعمل DNS-over-TLS على تحسين الخصوصية والأمان بين البرامج وبرامج التعيين. يُكمّل هذا الإجراء ملحقات أمان نظام أسماء النطاقات (DNSSEC) ويحمي النتائج التي تم التحقّق منها باستخدام ملحقات أمان نظام أسماء النطاقات (DNSSEC) من أي تعديل أو انتحال في طريق وصوله إلى العميل.
آلية العمل
يمكن لنظام العميل استخدام معالجة نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS) من خلال أحد الملفين الشخصيين:
الصارم أو الخصوصية الفرصة. باستخدام الملف الشخصي الصارم للخصوصية، يضبط المستخدم اسم خادم نظام أسماء النطاقات (اسم نطاق المصادقة في RFC 8310)
لخدمة نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS)، ويجب أن يكون العميل قادرًا على إنشاء اتصال بروتوكول أمان طبقة النقل (TLS) آمن
على المنفذ 853 إلى خادم نظام أسماء النطاقات. ويُعد الفشل في إنشاء اتصال آمن خطأ صعب ولن يؤدي إلى أي خدمة نظام أسماء نطاقات للعميل.
باستخدام الملف الشخصي الاستغلالي للخصوصية، يمكن للمستخدم إعداد عنوان IP لخادم نظام أسماء النطاقات مباشرةً أو الحصول عليه من الشبكة المحلية (باستخدام بروتوكول DHCP أو بعض الوسائل الأخرى). يحاول برنامج تعيين العميل إنشاء اتصال آمن
على المنفذ 853 بخادم نظام أسماء النطاقات المحدد. إذا تم إنشاء اتصال آمن، فإن ذلك يوفر خصوصية
لاستعلامات المستخدم من المراقبين السلبيين على المسار. ونظرًا لأن العميل لا يتحقق من صحة الخادم، فهو غير محمي من مهاجم نشط.
وإذا لم يتمكن العميل من إنشاء اتصال آمن على المنفذ 853، سيعاود
الاتصال بخادم نظام أسماء النطاقات على منفذ نظام أسماء النطاقات القياسي 53 عبر UDP أو TCP
بدون أي أمان أو خصوصية. والهدف من استخدام "الخصوصية الانتهازية" هو دعم النشر المتزايد لمستوى الخصوصية بهدف تبنّي الملف الشخصي الصارم للخصوصية على نطاق واسع.
عند استخدام ملف شخصي صارم للخصوصية، تنشئ برامج تعيين الكعب اتّصالًا بنظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS) باستخدام الخطوات التالية.
يتم ضبط برنامج حل التنويع اللغوي باستخدام اسم برنامج تعيين نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS)
dns.google.
يحصل برنامج تعيين الوصل على عناوين IP لـ dns.google باستخدام برنامج تعيين نظام أسماء النطاقات المحلي.
يجري محلل التبعثر اتصال TCP بالمنفذ 853 في عنوان IP هذا.
يبدأ محلل الكعب عملية تأكيد الاتصال عبر بروتوكول أمان طبقة النقل (TLS) باستخدام برنامج تعيين نظام أسماء النطاقات العام من Google.
يعرض خادم "نظام أسماء النطاقات العام من Google" شهادة بروتوكول أمان طبقة النقل (TLS) مع سلسلة كاملة من شهادات بروتوكول أمان طبقة النقل (TLS) وصولاً إلى شهادة جذر موثوق بها.
يتحقّق برنامج تعيين ال مكعب من هوية الخادم بناءً على الشهادات المقدمة.
إذا لم يتم التحقق من الهوية، سيتعذر تحليل اسم نظام أسماء النطاقات وسيعرض محلل الكعب رسالة خطأ.
بعد إنشاء اتصال بروتوكول أمان طبقة النقل (TLS)، يتوفر لدى برنامج تعيين التردّدات مسار اتصال آمن
بين خادم نظام أسماء النطاقات العام من Google.
يمكن الآن لأداة تعيين الكعب إرسال طلبات بحث نظام أسماء النطاقات وتلقي الردود عبر
الاتصال.
عند استخدام ملف شخصي غير مناسب للخصوصية، يحاول العميل أولاً إنشاء اتصال آمن عبر بروتوكول أمان طبقة النقل (TLS) إلى الخادم. يتم ذلك بشكل مشابه لما سبق مع وجود اختلاف
واحد مهم: لا يتم إجراء التحقق من صحة الشهادة من قبل العميل.
وهذا يعني أنه لا يمكن الوثوق بهوية الخادم. وإذا تعذّر إنشاء اتصال بروتوكول أمان طبقة النقل (TLS) على المنفذ 853 إلى الخادم، يعود محلل الكعب إلى التحدث إلى خادم نظام أسماء النطاقات عبر المنفذ 53.
الخصوصية
تنطبق سياسة الخصوصية على خدمة معالجة نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS).
في 27 حزيران (يونيو) 2019/2027، أعدنا تفعيل الشبكة الفرعية لعميل EDNS (ECS)
لخدمة نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS). تم إيقاف ECS عند إطلاق الخدمة.
دعم المعايير
يطبّق نظام أسماء النطاقات العام من Google نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (TLS) استنادًا إلى RFC 7858.
بالإضافة إلى ذلك، نوفّر الاقتراحات التالية لتوفير خدمة نظام أسماء نطاقات عالية الجودة وسريعة الاستجابة.
راجِع instructions لضبطه على جهاز يعمل بنظام التشغيل Android 9 (Pie) أو إصدار أحدث.
إنّ بروتوكول DNS-over-TLS متوافق أيضًا مع خدمة DNS64 العامة من Google التي تستخدم بروتوكول IPv6 فقط. تجدر الإشارة إلى أنّه لا يُنصح بإعداد نظام أسماء النطاقات (DNS64)
لجهاز جوّال سيتم توصيله بشبكات متعددة، لأنّ
نظام أسماء النطاقات (DNS64)
لا يعمل إلا عند توفُّر بروتوكول IPv6.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eGoogle Public DNS offers DNS resolution over TLS to enhance privacy and security between clients and resolvers, protecting against eavesdropping and spoofing.\u003c/p\u003e\n"],["\u003cp\u003eDNS-over-TLS operates using strict or opportunistic privacy profiles, with strict requiring authenticated connections to a specific server and opportunistic allowing fallback to unencrypted DNS if TLS fails.\u003c/p\u003e\n"],["\u003cp\u003eClient systems using DNS-over-TLS establish a secure connection by verifying the server's identity through TLS certificates, ensuring data is exchanged over an encrypted channel.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS supports standards such as TLS 1.3, TCP Fast Open, and DNS Transport over TCP to provide a high-quality and low-latency service.\u003c/p\u003e\n"],["\u003cp\u003eUsers can configure DNS-over-TLS on devices running Android 9 or higher and also utilize it with the IPv6-only Google Public DNS64 service, though the latter is not recommended for mobile devices on multiple networks.\u003c/p\u003e\n"]]],["DNS-over-TLS encrypts DNS queries and responses, enhancing privacy and security. It operates in two profiles: *strict* and *opportunistic*. Strict requires secure TLS connection verification on port 853, failing if validation fails. Opportunistic attempts secure connection on 853 but falls back to unsecured port 53 if it fails, without validating the server. Clients using strict profile resolve the server name, establish a TLS connection on port 853, and validate the server's certificate. Google Public DNS supports this method and follows related RFC specifications.\n"],null,["# DNS-over-TLS\n\nIntroduction\n------------\n\nTraditional DNS queries and responses are sent over UDP or TCP without\nencryption.\nThis is vulnerable to eavesdropping and spoofing\n(including DNS-based Internet filtering).\nResponses from recursive resolvers to clients are the most vulnerable to\nundesired or malicious changes, while communications between recursive resolvers\nand authoritative name servers often incorporate\n[additional protection](/speed/public-dns/docs/security#mitigations).\n\nTo address these problems, Google Public DNS offers DNS resolution over\nTLS-encrypted TCP connections as specified by [RFC 7858](https://tools.ietf.org/html/rfc7858).\nDNS-over-TLS improves privacy and security between clients and resolvers. This\ncomplements DNSSEC and protects DNSSEC-validated results from modification or\nspoofing on the way to the client.\n\nHow it Works\n------------\n\n| **Note:** This section gives an overview of DNS-over-TLS operation when talking to the Google Public DNS resolver (with the name `dns.google`). If you are interested in more details, please read the RFCs [Specification for DNS over Transport Layer Security](https://tools.ietf.org/html/rfc7858) and [Usage Profiles for DNS over TLS and DNS over DTLS](https://tools.ietf.org/html/rfc8310).\n\nA client system can use DNS-over-TLS with one of [two profiles](https://tools.ietf.org/html/rfc8310#section-5):\n*strict* or *opportunistic* privacy. With the strict privacy profile, the user\nconfigures a DNS server name (the *authentication domain name* in\n[RFC 8310](https://tools.ietf.org/html/rfc8310#section-2))\nfor DNS-over-TLS service and the client must be able to create a secure TLS\nconnection on port 853 to the DNS server. Failure to establish a secure\nconnection is a hard error and will result in no DNS service for the client.\n\nWith the opportunistic privacy profile, the DNS server IP address may be\nconfigured directly by the user or obtained from the local network (using DHCP\nor some other means). The client resolver attempts to establish a secure\nconnection on port 853 to the specified DNS server. If a secure connection is\nestablished, this provides privacy for the user's queries from passive observers\non the path. Since the client does not verify the authenticity of the server it\nis not protected from an active attacker.\nIf the client cannot establish a secure connection on port 853, it falls back to\ncommunicating with the DNS server on the standard DNS port 53 over UDP or TCP\nwithout any security or privacy. The use of Opportunistic Privacy is intended to\nsupport incremental deployment of increased privacy with a view to widespread\nadoption of the strict privacy profile.\n\nWhen using a strict privacy profile, stub resolvers establish a DNS-over-TLS\nconnection with the following steps.\n\n1. The stub resolver is configured with the DNS-over-TLS resolver name `dns.google`.\n2. The stub resolver obtains the IP address(es) for `dns.google` using the local DNS resolver.\n3. The stub resolver makes a TCP connection to port 853 at the one those IP address.\n4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.\n5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.\n6. The stub resolver verifies the server's identity based on the certificates presented.\n - If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.\n7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.\n8. Now the stub resolver can send DNS queries and receive responses over the connection.\n\nWhen using an opportunistic privacy profile, the client first attempts to create\na secure TLS connection to the server. This is done similarly to the above with\none important difference - no certificate validation is performed by the client.\nThis means the identity of the server cannot be trusted. If a TLS connection on\nport 853 to the server cannot be established, the stub resolver falls back to\ntalking to the DNS server on port 53.\n| **Note:** To prevent denial of service attacks and resource exhaustion on the server, Google Public DNS may close DNS-over-TLS connections that have been idle too long or when a large number of queries have been received on the connection. The next time the client needs to perform DNS queries, the stub resolver will repeat the steps above to re-establish a connection to the Google Public DNS resolver.\n\nPrivacy\n-------\n\nOur [privacy policy](/speed/public-dns/privacy) applies to the DNS-over-TLS service.\n\nOn 2019/06/27 we have re-enabled [EDNS client subnet (ECS)](/speed/public-dns/docs/ecs)\nfor the DNS-over-TLS service. ECS was disabled at the launch of the service.\n\nStandards Support\n-----------------\n\nGoogle Public DNS implements DNS-over-TLS based on [RFC 7858](https://tools.ietf.org/html/rfc7858).\nIn addition we support the following recommendations to provide a high quality\nand low-latency DNS service.\n\n- [TLS 1.3 (RFC 8846)](https://tools.ietf.org/html/rfc8446)\n- [TCP Fast Open (RFC 7413)](https://tools.ietf.org/html/rfc7413)\n- [DNS Transport over TCP Implementation Requirements (RFC 7766)](https://tools.ietf.org/html/rfc7766)\n\nStart Using It\n--------------\n\nSee [instructions](/speed/public-dns/docs/using#android) to configure it on a\ndevice with Android 9 (Pie) or higher.\n\nDNS-over-TLS is also supported for the IPv6-only\n[Google Public DNS64 service](/speed/public-dns/docs/dns64#secure). Note that configuring DNS64 for a\nmobile device that will attach to multiple networks is not recommended, as DNS64\nonly works when IPv6 is available."]]
