i18n/i18n/ar/advanced/dns-overview.md

title, icon, description

title	icon	description
نظرة عامة على DNS	material/dns	نظام أسماء النطاقات DNS يشبه دليل الهاتف للإنترنت؛ فهو يساعد المتصفح على العثور على الموقع الذي تريد زيارته.

يُعد نظام أسماء النطاقات (DNS) بمثابة “دليل الهاتف للإنترنت”. عندما تكتب اسم موقع، يحوله DNS إلى عنوان IP، حتى يعرف المتصفح أين يجد الموقع، وذلك عبر شبكة من الخوادم المنتشرة.

ما هو الـ DNS؟

عندما تفتح موقعا، يحصل المتصفح على عنوان رقمي يساعده في الوصول إليه. مثلا، عند فتح privacyguides.org، يحصل المتصفح على العنوان 192.98.54.105.

ظهر DNS منذ البدايات الأولى للإنترنت. غالبًا ما تكون طلبات الـ DNS بين جهازك وخوادم الـ DNS غير مشفرة. عادةً في المنزل، يعطي مزود خدمة الإنترنت (ISP) جهازك خوادم DNS باستخدام DHCP.

طلبات DNS غير المشفرة يمكن أن تُراقَب وتُعدل بسهولة وهي في طريقها بين جهازك والخادم. في بعض البلدان، يُطلب من مزودي خدمة الإنترنت استخدام طريقة بسيطة في تصفية DNS (DNS filtering) لحجب بعض المواقع. إذا طلبت عنوان IP لموقع محجوب، فقد لا يستجيب الخادم، أو قد يعطيك عنوان IP مختلفا. لأن DNS غير مشفر، يستطيع مزود خدمة الإنترنت أو مشغل الشبكة استخدام DPI لرؤية الطلبات التي ترسلها. قد يحجب مزود خدمة الإنترنت بعض الطلبات لأنها تشبه طلبات معينة، حتى لو كنت تستخدم خادم DNS مختلفا.

في القسم التالي، نوضح بتجربة بسيطة ما الذي قد يراه شخص يراقب من الخارج عند استخدام DNS عادي غير مشفر وDNS مشفر.

الـ DNS غير المشفر

1. من خلال tshark، وهو جزء من Wireshark، نستطيع رؤية حزم الإنترنت (الـ internet packets) أثناء انتقالها وتسجيلها. هذا الأمر يسجل حزم البيانات (الـ packets) التي توافق الشروط المحددة:

   tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
   

2. بعدها، نستخدم dig على Linux وmacOS، أو nslookup على Windows، لنسأل كلا الخادمين عن عنوان DNS. البرامج، مثل المتصفحات، تسأل عن عناوين الـ DNS تلقائيا، إلا إذا تم ضبطها على استخدام DNS مشفر.

   === "Linux, macOS"

    ```
    dig +noall +answer privacyguides.org @1.1.1.1
    dig +noall +answer privacyguides.org @8.8.8.8
    ```
   

   === "Linux, macOS"

    ```
    nslookup privacyguides.org 1.1.1.1
    nslookup privacyguides.org 8.8.8.8
    ```
   

3. بعد ذلك، نريد تحليل النتائج:

   === "Wireshark"

    ```
    wireshark -r /tmp/dns.pcap
    ```
   

   === "tshark"

    ```
    tshark -r /tmp/dns.pcap
    ```
   

عند تشغيل أمر Wireshark السابق، سترى في الجزء العلوي “الإطارات (الـ frames)”، وفي الجزء السفلي ستظهر جميع المعلومات عن الإطار (الـ frame) الذي اخترته. تستطيع أنظمة التصفية والمراقبة الخاصة (الـ filtering and monitoring) بالمؤسسات، مثل الأنظمة التي تشتريها الحكومات، القيام بهذه العملية تلقائيا من دون أي تدخل من الإنسان، ثم جمع هذه الإطارات (الـ frames) لاستخراج بيانات إحصائية يستفيد منها مراقب الشبكة.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standard query 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standard query 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

يمكن للمراقب تعديل أي من هذه الحزم (الـ packets).

ما هو "الـ DNS المشفر"؟

عند الحديث عن الـ DNS المشفر، فقد نقصد واحدا من عدة طرق لحماية طلبات الـ DNS، مثل DNSCrypt وDNS over TLS وDNS over HTTPS.

DNSCrypt

كان DNSCrypt من أوائل الطرق التي جعلت طلبات الـ DNS محمية بالتشفير. يستخدم DNSCrypt المنفذ (الـ port) 443، ويمكنه إرسال البيانات باستخدام TCP أو UDP. لم يُقدم DNSCrypt رسميا إلى فريق هندسة الإنترنت IETF، ولم يمر بخطوات طلب التعليقات RFC، لذلك لم ينتشر كثيرا، وبقي مستخدما فقط في بعض التطبيقات. لذلك، أصبح الناس يستخدمون DNS over HTTPS الأكثر انتشارا بدلا منه في أغلب الأحيان.

DNS over TLS (DoT)

هناك طريقة أخرى لحماية اتصال DNS بالتشفير، وهي DNS over TLS، وقد شرحت في RFC 7858. بدأت الأنظمة في دعم هذه الميزة مع Android 9 وiOS 14، وعلى Linux من خلال systemd-resolved بدءً من الإصدار 237. في السنوات الأخيرة، صار المجال التقني يفضل DoH أكثر من DoT، لأن DoT بروتوكول معقد، ولأن تطبيقاته لا تتبع معيار RFC دائما بالطريقة نفسها. يعمل DoT على منفذ (port) خاص اسمه 853، لذلك يمكن للجدران النارية (الـ firewalls) الصارمة أن تحجبه بسهولة.

DNS over TLS (DoT)

يعمل DNS over HTTPS، كما يشرحه RFC 8484، على إرسال طلبات DNS داخل HTTP/2، ثم يحميها باستخدام HTTPS. بدأت بعض متصفحات الويب بدعم هذه الميزة، مثل Firefox 60 وChrome 83.

بدأت الأنظمة مثل iOS 14 وmacOS 11 وMicrosoft Windows وAndroid 13 بدعم DoH بشكل مدمج، ولكن هذا الدعم لا يكون مفعلا تلقائيا. على أجهزة Linux، ما زال الدعم العام ينتظر أن يوفر systemd هذه الميزة، لذلك تحتاج حاليًا إلى تثبيت برنامج خارجي.

دعم أنظمة التشغيل دون برامج إضافية

Android

يدعم أندرويد ٩ وما بعده أنظمة أسماء النطاقات عبر أمن طبقة النقل (DNS over TLS). تجد هذا الإعداد في: الإعدادات ← ** الشبكة والإنترنت ** ← نظام أسماء نطاقات خاص.

أجهزة أبل

تدعم آخر إصدارات آي‌أو‌إس و آيباد‌أو‌إس و تي‌في‌أو‌إس و ماك‌أو‌إس أنظمة DoT و DoH. يوجد دعم أصيل لهذه الموافيق باستخدام ملفَّات تعريف الضبط أو باستخدام واجهة برمجة إعدادات نظام تسمية النطاقات.

لك اختيار ضبط نظام تسمية النطاقات بعد تثبيت ملفِّ تعريف ضبط أو تثبيت تطبيق يستخدم واجهة برمجة إعدادات نظام تسمية النطاقات. إن كانت شبكة خاصَّة افتراضية (VPN) مفعَّلةً فسوف تُحلَّل الاتصالات داخلها باستخدام نظام تسمية نطاقاتها وليس باستخدام إعدادات نظامك.

لا تتيح أبل واجهةً أصيلةً لإنشاء ملفَّات تعريف معمَّاة. مُنشئ ملفَّات تعريف نظام تسمية النطاقات الآمن هو أداة غير رسمية تتيح لك إنشاء ملفَّات تعريف نظام تسمية النطاقات معمَّاة، ولكن ضع في حسبانك أنها لن توقَّع. تفضَّل ملفَّات التعريف الموقَّعة على غيرها، وذلك ﻷن التوقيع يؤكِّد أصلها وصحَّتها. تعلَّم ملفَّات التعريف الموقَّعة بعلامة «مؤكَّد» خضراء. لتستزيد علمًا عن توقيع الرموز عليك مطالعة عن توقيع الرموز.

لينكس

تعتمد كثير من توزيعات Linux على systemd-resolved لإجراء طلبات الـ DNS، لكن هذه الأداة لا تدعم DoH بعد. إذا كنت تريد استخدام DoH، فعليك تثبيت وسيط مثل dnscrypt-proxy وضبطه لكي يأخذ طلبات الـ DNS من النظام ويمررها عبر HTTPS.

ما الذي يستطيع طرف خارجي رؤيته؟

In this example we will record what happens when we make a DoH request:

1. أولا، قم بتشغيل أداة tshark:

   tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
   

2. ثانيا، قم بإرسال طلب باستخدام curl:

   curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
   

3. بعد إرسال الطلب، يمكنك إيقاف عملية التقاط الحزم بالضغط (packet capture) على CTRL+ C.

4. والآن، دعنا نُحلل البيانات التي حصلنا عليها في Wireshark:

   wireshark -r /tmp/dns_doh.pcap
   

يمكننا رؤية عملية إنشاء الاتصال و TLS handshake التي تحدث مع أي اتصال مشفر. إذا تصفحت حزم البيانات التالية الخاصة بالتطبيق، ستلاحظ أنها لا تُظهر اسم النطاق الذي طلبته ولا عنوان الـ IP الذي رجع إلينا، فالبيانات أصبحت مخفية تماما.

لماذا لا ينبغي لي استخدام DNS مشفر؟

في الأماكن التي تفرض رقابة أو تصفية للإنترنت، قد تترتب على زيارة المصادر المحظورة عواقب خاصة بها، وهو أمر يجب عليك مراعاته في نموذج التهديد الخاص بك. لا نقترح استخدام DNS المشفر لهذا الغرض. استخدم Tor أو VPN بدلا من ذلك. إذا كنت تستخدم شبكة الـ VPN، فمن الضروري الاعتماد على خوادم الـ DNS الخاصة بمزود الخدمة نفسه. عند استخدام الـ VPN، فإنك تضع ثقتك الكاملة في مزود الخدمة بالفعل، وتأتمنه على كافة أنشطتك وتحركاتك عبر الشبكة.

عندما نقوم بإجراء استعلام من خلال الـ DNS، فغالبا ما يكون ذلك بسبب رغبتنا في الوصول إلى مصدر معين على الشبكة. في السطور التالية، سنناقش بعض الطرق التي قد تتسبب في كشف أنشطة تصفحك، حتى عند استخدامك لبروتوكول الـ DNS المشفّر:

الـ IP Address

قد تكون أسهل طريقة لمعرفة نشاط تصفحك هي النظر إلى عناوين الـ IP التي تتصل بها أجهزتك. ببساطة، إذا كان من يراقب الشبكة يعلم مسبقا أن عنوان privacyguides.org هو 198.98.54.105، ولاحظ أن جهازك يتصل بهذا العنوان تحديداً، فسوف يستنتج بسهولة أنك تتصفح موقع Privacy Guides.

تكون هذه الطريقة مفيدة فقط عندما ينتمي عنوان الـ IP إلى خادم (Server) يستضيف عددا قليلا من المواقع. It's also not very useful if the site is hosted on a shared platform (e.g. GitHub Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc.). علاوة على ذلك، فإنه يفقد الكثير من فائدته إذا كانت استضافة الخادم تتم خلف reverse proxy.

Server Name Indication (SNI)

يُستخدم الـ Server Name Indication عادة عندما يستضيف عنوان IP العديد من مواقع الويب. قد يتمثل ذلك في خدمة مثل Cloudflare، أو أي نظام آخر للحماية من هجمات الـ (Denial-of-service attack).

1. ابدأ التتبع مرة أخرى باستخدام tshark. لقد أضفنا عامل تصفية بناءً على عنوان IP الخاص بنا، لكي تتجنب التقاط الكثير من الـ packets:

   tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
   

2. بعد ذلك، نقوم بزيارة https://privacyguides.org.

3. بعد زيارة الموقع، نريد إيقاف تسجيل الـ packets بالضغط على CTRL + C.

4. بعد ذلك، نريد تحليل النتائج:

   wireshark -r /tmp/pg.pcap
   

   سنرى بدء الاتصال، وبعده الـ TLS handshake لموقع Privacy Guides. حوالي الـ frame رقم 5. سترى رسالة «Client Hello».

5. افتح رمز المثلث ▸ بجوار كل حقل:

   ▸ Transport Layer Security
     ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
       ▸ Handshake Protocol: Client Hello
         ▸ Extension: server_name (len=22)
           ▸ Server Name Indication extension
   

6. يمكننا ملاحظة قيمة SNI، وهي التي تفصح عن هوية موقع الويب الذي نقوم بزيارته. The tshark command can give you the value directly for all packets containing a SNI value:

   tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
   

وهذا يعني أنه حتى وإن استخدمنا خوادم الـ "Encrypted DNS"، فمن المرجح أن يُفصح عن النطاق عبر SNI. يجلب بروتوكول TLS v1.3 معه تقنية Encrypted Client Hello، مما يمنع حدوث هذا النوع من التسريبات.

الحكومات، وخاصة الصين وروسيا، إما أنها بدأت بالفعل في حظره أو أعربت عن رغبتها في القيام بذلك. مؤخرًا، روسيا بدأت في حظر المواقع الأجنبية التي تعتمد على الـ HTTP/3. وهذا لأن بروتوكول QUIC الذي يعتبر جزءًا من HTTP/3 يتطلب أن يكون ClientHello مشفرا أيضا.

Online Certificate Status Protocol (OCSP)

هناك طريقة أخرى قد تجعل متصفحك يكشف المواقع التي تزورها، وهي عبر الـ Online Certificate Status Protocol. عند دخولك إلى موقع يستخدم HTTPS، قد يتحقق المتصفح من شهادة الموقع ليرى هل ما زالت صالحة أم تم إلغاؤها. عادة يستخدم المتصفح HTTP لفعل ذلك، وهذا يعني أن الطلب غير مشفر.

يحتوي طلب OCSP على"الرقم التسلسلي (serial number)" للشهادة، وهورقم فريد من نوعه. يرسل المتصفح هذا الطلب إلى “الـ OCSP responder” حتى يتأكد من حالة الشهادة.

نستطيع تقليد ما يقوم به المتصفح باستخدام أمر openssl.

1. احصل على شهادة الخادم، ثم استخدم sed حتى تحفظ الجزء المهم فقط في ملف:

   openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
       sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
   

2. احصل على الشهادة الوسيطة. عادةً لا توقّع الـ CA الشهادة مباشرةً، بل تستخدم شهادة أخرى في المنتصف تُسمّى “الشهادة الوسيطة (intermediate" certificate)”.

   openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
       sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
   

3. أول شهادة داخل pg_and_intermediate.cert هي في الحقيقة شهادة الخادم من الخطوة الأولى. نستطيع استخدام sed مجددا لحذف كل ما يسبق أول ظهور لـ END:

   sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
       /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
   

4. استخرج OCSP responder من شهادة الخادم:

   openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
   

   تبين الشهادة لدينا الـ Lets Encrypt certificate responder. إذا أردنا رؤية كل تفاصيل الشهادة، يمكننا استخدام الأمر التالي:

   openssl x509 -text -noout -in /tmp/pg_server.cert
   

5. ابدأ التقاط حزم البيانات (الـ packet):

   tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
   

6. قم بإرسال طلب الـ OCSP:

   openssl ocsp -issuer /tmp/intermediate_chain.cert \
                -cert /tmp/pg_server.cert \
                -text \
                -url http://r3.o.lencr.org
   

7. Open the capture:

   wireshark -r /tmp/pg_ocsp.pcap
   

   سترى حزمتين مرتبطتين ببروتوكول “OCSP”: واحدة ترسل الطلب “Request”، والأخرى تحمل الرد “Response”. في طلب “Request”، يمكنك إظهار “الرقم التسلسلي (الـ serial number)” عن طريق فتح المثلث ▸ الموجود بجانب كل خانة:

   ▸ Online Certificate Status Protocol
     ▸ tbsRequest
       ▸ requestList: 1 item
         ▸ Request
           ▸ reqCert
             serialNumber
   

   في الاستجابة “Response”، يظهر “الرقم التسلسلي (الـ serial number)” أيضا:

   ▸ Online Certificate Status Protocol
     ▸ responseBytes
       ▸ BasicOCSPResponse
         ▸ tbsResponseData
           ▸ responses: 1 item
             ▸ SingleResponse
               ▸ certID
                 serialNumber
   

8. أو استخدم tshark للبحث داخل الحزم (الـ packets) عن الرقم التسلسلي (الـ serial number):

   tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
   

بما أن الشهادة العامة (public certificate) متاحة للجميع، يمكن لمراقب الشبكة مقارنة الرقم التسلسلي (الـ serial number) بها، ثم يعرف من ذلك الموقع الذي تزوره. يمكن جعل هذه العملية تعمل تلقائيا، فتربط بين عناوين IP والأرقام التسلسلية (الـ serial numbers). يمكن أيضا البحث داخل سجلات الـ Certificate Transparency عن هذا الرقم التسلسلي (serial number).

هل ينبغي أن أستخدم DNS مشفرا؟

صممنا هذا المخطط الانسيابي لمساعدتك على معرفة متى ينبغي استخدام DNS مشفر:

Start[البداية] --> anonymous{هل تحاول أن تكون<br> مجهول الهوية؟}
    anonymous --> | نعم | tor(استخدم Tor)
anonymous --> | لا | censorship{هل تحاول تجنب<br> الرقابة؟}
    censorship --> | نعم | vpnOrTor(استخدم<br> VPN أو Tor)
censorship --> | لا | privacy{هل تريد حماية خصوصيتك<br> من مزوّد خدمة الإنترنت؟}
    privacy --> | نعم | vpnOrTor
privacy --> | لا | obnoxious{هل يقوم مزوّد خدمة الإنترنت<br> بإعادة توجيه مزعجة؟<br>}
    obnoxious --> | نعم | encryptedDNS(استخدم<br> DNS مشفرا<br> من مزود آخر)
obnoxious --> | لا | ispDNS{هل يوفر مزوّد خدمة الإنترنت<br> DNS مشفرا؟}
    ispDNS --> | نعم | useISP(استخدم<br> DNS مشفرا<br> من مزود خدمة الإنترنت)
ispDNS --> | لا | nothing(لا تحتاج إلى فعل شيء)

لا تستخدم DNS مشفرا من مزود آخر إلا إذا كنت تريد تجاوز إعادة التوجيه أو الـ DNS blocking ، وكنت متأكدا من أن ذلك لن يسبب لك مشكلة، أو إذا كنت تريد مزودا يوفر بعض التصفية البسيطة.

قائمة خوادم الـ DNS الموصى بها{.md-button}

ما هو الـ DNSSEC؟

(DNSSEC) هي ميزة في DNS تساعد على التأكد من أن الردود على طلبات أسماء النطاقات صحيحة. هي لا تحمي خصوصية هذه الطلبات، بل تمنع المهاجمين من تغيير ردود الـ DNS أو إفسادها.

بمعنى أبسط، يضيف DNSSEC توقيعا رقميا إلى البيانات حتى يساعد على التأكد من أنها صحيحة. حتى يكون استعلام الـ DNS آمنا، يحدث التوقيع في كل مرحلة من مراحل عملية البحث. ونتيجة لذلك، يمكن الوثوق بجميع الردود القادمة من DNS.

يمكن تشبيه توقيع DNSSEC بتوقيع شخص على ورقة قانونية بقلم؛ فلكل شخص توقيع مميز لا يستطيع الآخرون تقليده، ويمكن للخبير أن يفحصه ويتأكد من أن الشخص نفسه هو من وقع الوثيقة. تساعد هذه التوقيعات الرقمية على التأكد من أن البيانات لم يتم تغييرها أو العبث بها.

يطبق DNSSEC سياسة توقيع رقمي هرمية عبر جميع طبقات DNS. على سبيل المثال، عند البحث عن privacyguides.org، سيقوم خادم الـ root بتوقيع مفتاح لخادم أسماء .org، وبعدها سيقوم خادم أسماء .org بتوقيع مفتاح للخادم الرئيسي الخاص بـ privacyguides.org.

Adapted from DNS Security Extensions (DNSSEC) overview by Google and DNSSEC: An Introduction by Cloudflare, both licensed under CC BY 4.0.

What is QNAME minimization?

A QNAME is a "qualified name", for example discuss.privacyguides.net. In the past, when resolving a domain name your DNS resolver would ask every server in the chain to provide any information it has about your full query. In this example below, your request to find the IP address for discuss.privacyguides.net gets asked of every DNS server provider:

Server	Question Asked	Response
Root server	What's the IP of discuss.privacyguides.net?	I don't know, ask .net's server...
.net's server	What's the IP of discuss.privacyguides.net?	I don't know, ask Privacy Guides' server...
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190!

With "QNAME minimization," your DNS resolver now only asks for just enough information to find the next server in the chain. In this example, the root server is only asked for enough information to find the appropriate nameserver for the .net TLD, and so on, without ever knowing the full domain you're trying to visit:

Server	Question Asked	Response
Root server	What's the nameserver for .net?	Provides .net's server
.net's server	What's the nameserver for privacyguides.net?	Provides Privacy Guides' server
Privacy Guides' server	What's the nameserver for discuss.privacyguides.net?	This server!
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190

While this process can be slightly more inefficient, in this example neither the central root nameservers nor the TLD's nameservers ever receive information about your full query, thus reducing the amount of information being transmitted about your browsing habits. Further technical description is defined in RFC 7816.

What is EDNS Client Subnet (ECS)?

The EDNS Client Subnet is a method for a recursive DNS resolver to specify a subnetwork for the host or client which is making the DNS query.

It's intended to "speed up" delivery of data by giving the client an answer that belongs to a server that is close to them such as a content delivery network, which are often used in video streaming and serving JavaScript web apps.

This feature does come at a privacy cost, as it tells the DNS server some information about the client's location, generally your IP network. For example, if your IP address is 198.51.100.32 the DNS provider might share 198.51.100.0/24 with the authoritative server. Some DNS providers anonymize this data by providing another IP address which is approximately near your location.

If you have dig installed you can test whether your DNS provider gives EDNS information out to DNS nameservers with the following command:

dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Note that this command will contact Google for the test, and return your IP as well as EDNS client subnet information. If you want to test another DNS resolver you can specify their IP, to test 9.9.9.11 for example:

dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

If the results include a second edns0-client-subnet TXT record (like shown below), then your DNS server is passing along EDNS information. The IP or network shown after is the precise information which was shared with Google by your DNS provider.

o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE  rcvd: 130