RESOLVECTL(1)

resolvectl

RESOLVECTL(1)

الاسم¶

resolvectl, resolvconf - حل أسماء النطاقات، وعناوين IPv4 وIPv6، وسجلات موارد DNS، والخدمات؛ فحص وإعادة تشكيل محلل DNS

موجز¶

resolvectl [خيارات...] {أمر} [اسم...]

الوصف¶

يمكن استخدام resolvectl لحل أسماء النطاقات، وعناوين IPv4 وIPv6، وسجلات موارد DNS والخدمات مع خدمة المحلل systemd-resolved.service(8). مبدئيًا، تُحل قائمة المعاملات المحددة كأسماء مضيفين، مع استرداد عناوين IPv4 وIPv6 الخاصة بها. إذا كانت المعاملات المحددة منسقة كعناوين IPv4 أو IPv6، تُجرى العملية العكسية، ويُسترد اسم مضيف للعناوين المحددة.

يحتوي مخرج البرنامج على معلومات حول البروتوكول المستخدم للبحث وواجهة الشبكة التي اكتُشفت فيها البيانات. يحتوي أيضًا على معلومات حول ما إذا كان يمكن استيثاق المعلومات. تُعتبر جميع البيانات التي ينجح فيها التحقق المحلي من DNSSEC موثقة. علاوة على ذلك، تُبلغ جميع البيانات القادمة من مصادر محلية موثوقة كموثقة أيضًا، بما في ذلك حل اسم المضيف المحلي، واسم المضيف "localhost" أو جميع البيانات من /etc/hosts.

الأوامر¶

query اسم_مضيف|عنوان...

حل أسماء النطاقات، بالإضافة إلى عناوين IPv4 وIPv6. عند استخدامه مع --type= أو --class= (انظر أدناه)، يُحل سجلات موارد DNS منخفضة المستوى.

إذا حُدد اسم نطاق أحادي التسمية، يُبحث عنه وفقًا لنطاقات البحث المهيأة — ما لم يُحدد --search=no أو --type=/--class=، وكلاهما يعطل هذا المنطق.

إذا حُدد اسم نطاق دولي، يُترجم آليًا وفقًا لقواعد IDNA عند حله عبر DNS الكلاسيكي — ولكن ليس للبحث عبر MulticastDNS أو LLMNR. إذا استُخدم --type=/--class=، تُعطل ترجمة IDNA وتُعالج أسماء النطاقات كما هو محدد.

إذا دُمج مع --json= (مدعوم فقط مع --type=)، سيُخرج بيانات سجل المورد في كائن JSON.

أُضيف في الإصدار 239.

service [[اسم] نوع] نطاق

حل خدمات RFC 6763 DNS-SD[1] و RFC 2782 SRV[2]، اعتمادًا على قائمة المعاملات المحددة. إذا مُررت ثلاثة معاملات، يُفترض أن الأول هو اسم خدمة DNS-SD، والثاني نوع خدمة SRV، والثالث النطاق للبحث فيه. في هذه الحالة، يُنفذ بحث كامل بنمط DNS-SD لـ SRV و TXT. إذا حُدد معاملان فقط، يُفترض أن الأول هو نوع خدمة SRV، والثاني النطاق للبحث فيه. في هذه الحالة، لا يُطلب سجل مورد TXT. أخيرًا، إذا حُدد معامل واحد فقط، يُفترض أنه اسم نطاق مسبوق بنوع SRV، ويُجرى بحث SRV (بدون TXT).

أُضيف في الإصدار 239.

openpgp بريد@نطاق...

الاستعلام عن مفاتيح PGP المخزنة كسجلات مورد OPENPGPKEY، انظر RFC 7929[3]. تُحول عناوين البريد الإلكتروني المحددة إلى اسم نطاق DNS المقابل، وتُطبع أي مفاتيح OPENPGPKEY.

أُضيف في الإصدار 239.

tlsa [عائلة] نطاق[:منفذ]...

الاستعلام عن مفاتيح TLS العامة المخزنة كسجلات مورد TLSA، انظر RFC 6698[4]. يُجرى استعلام لكل من الأسماء المحددة المسبوقة بالمنفذ والعائلة ("_منفذ._عائلة.نطاق"). يمكن تحديد رقم المنفذ بعد نقطتين (":")، وإلا سيُستخدم 443 مبدئيًا. يمكن تحديد العائلة كوسيطة أولى، وإلا سيُستخدم tcp.

أُضيف في الإصدار 239.

status [رابط...]

يعرض إعدادات DNS العامة وحسب الرابط السارية حاليًا. إذا لم يُحدد أمر، فهذا هو المبدئي الضمني.

أُضيف في الإصدار 239.

statistics

يعرض إحصائيات المحلل العامة، بما في ذلك معلومات حول ما إذا كان DNSSEC مفعلًا ومتاحًا، بالإضافة إلى إحصائيات الحل والتحقق.

أُضيف في الإصدار 239.

reset-statistics

يعيد تعيين عدادات الإحصائيات المعروضة في statistics إلى الصفر. تتطلب هذه العملية صلاحيات الجذر.

أُضيف في الإصدار 239.

flush-caches

يمسح جميع خبائن سجلات مورد DNS التي تحتفظ بها الخدمة محليًا. هذا مكافئ إلى حد كبير لإرسال SIGUSR2 إلى خدمة systemd-resolved.

أُضيف في الإصدار 239.

reset-server-features

يمسح جميع معلومات مستوى الميزات التي تعلمها الحلال عن خوادم محددة، ويضمن بدء منطق استقصاء ميزات الخادم من البداية مع طلب البحث التالي. هذا يعادل إلى حد كبير إرسال SIGRTMIN+1 إلى خدمة systemd-resolved.

أُضيف في الإصدار 239.

dns [LINK [SERVER...]], domain [LINK [DOMAIN...]], default-route [LINK [BOOL...]], llmnr [LINK [MODE]], mdns [LINK [MODE]], dnssec [LINK [MODE]], dnsovertls [LINK [MODE]], nta [LINK [DOMAIN...]]

يحصل/يضبط إعدادات DNS لكل واجهة. قد تُستخدم هذه الأوامر لتهيئة إعدادات DNS متنوعة لواجهات الشبكة. قد تُستخدم هذه الأوامر لإعلام systemd-resolved أو systemd-networkd بإعدادات DNS لكل واجهة المحددة عبر وسائل خارجية. يتوقع أمر dns مواصفات عنوان IPv4 أو IPv6 لخوادم DNS المستخدمة. يمكن لكل عنوان أن يأخذ اختيارياً رقم منفذ مفصولاً بـ ":"، واسم واجهة شبكة أو فهرس مفصولاً بـ "%"، وإشارة اسم خادم (SNI) مفصولة بـ "#". عند تحديد عنوان IPv6 برقم منفذ، يجب أن يكون العنوان بين قوسين مربعين. أي أن الصيغ الكاملة المقبولة هي "111.222.333.444:9953%ifname#example.com" لـ IPv4 و"[1111:2222::3333]:9953%ifname#example.com" لـ IPv6. يتوقع أمر domain نطاقات DNS صالحة، ربما مسبوقة بـ "~"، ويضبط نطاق بحث أو نطاق توجيه فقط لكل واجهة. يتوقع أمر default-route معلمة منطقية، ويضبط ما إذا كان يمكن استخدام الوصلة كمسار مبدئي لاستعلامات DNS، أي إذا كانت مناسبة لاستعلامات النطاقات التي لم تُضبط لها وصلة أخرى صراحة. قد تُستخدم أوامر llmnr وmdns وdnssec وdnsovertls لتهيئة إعدادات LLMNR وMulticastDNS وDNSSEC وDNSOverTLS لكل واجهة. أخيراً، قد يُستخدم أمر nta لتهيئة نطاقات NTA إضافية لـ DNSSEC لكل واجهة.

يمكن لأوامر dns وdomain وnta أن تأخذ وسيطة سلسلة فارغة واحدة لمسح قوائم القيم الخاصة بها.

للتفاصيل حول هذه الإعدادات، وقيمها الممكنة وتأثيرها، انظر الإعدادات المقابلة في systemd.network(5).

أُضيف في الإصدار 239.

revert LINK

يعيد إعدادات DNS لكل واجهة. إذا أُعيدت إعدادات DNS، تُعاد جميع إعدادات DNS لكل واجهة إلى مبدئياتها، مما يلغي جميع تأثيرات dns وdomain وdefault-route وllmnr وmdns وdnssec وdnsovertls وnta. لاحظ أنه عندما تختفي واجهة شبكة، تُفقد جميع الإعدادات آلياً، ولا حاجة لإعادة صريحة في تلك الحالة.

أُضيف في الإصدار 239.

monitor

يعرض تياراً مستمراً من استعلامات الحل للعميل المحلي واستجاباتها. عند اكتمال استعلام محلي، يُظهر مفتاح بحث مورد DNS وسجلات المورد للاستعلام. لاحظ أن هذا يعرض الاستعلامات الصادرة محلياً فقط، ولا يرتبط فوراً بطلبات DNS المقدمة إلى خوادم DNS المهيأة أو نطاقات LLMNR أو MulticastDNS، حيث قد تُجاب الاستعلامات من الخبيئة المحلية، أو قد تؤدي إلى معاملات DNS متعددة (مثلاً للتحقق من معلومات DNSSEC). إذا تبعتها سلاسل إعادة توجيه CNAME/CNAME، فسيُعرض استعلام منفصل لكل عنصر من السلسلة. استخدم --json= لتمكين إخراج JSON.

أُضيف في الإصدار 252.

show-cache

يعرض محتوى الخبيئة الحالي، لكل نطاق. استخدم --json= لتمكين إخراج JSON.

أُضيف في الإصدار 254.

show-server-state

يعرض معلومات حالة خادم مفصلة، لكل خادم DNS. استخدم --json= لتمكين إخراج JSON.

أُضيف في الإصدار 255.

log-level [المستوى]

إذا لم تُعطَ أي وسيطة، اطبع مستوى السجل الحالي للمدير. إذا وُفرت وسيطة اختيارية LEVEL، فسيقوم الأمر بتغيير مستوى السجل الحالي للمدير إلى LEVEL (يقبل نفس القيم الخاصة بـ --log-level= الموضحة في systemd(1)).

أُضيف في الإصدارة 244.

الخيارات¶

-4، -6

مبدئياً، عند حل اسم مضيف، تُحصل عناوين IPv4 وIPv6 معاً. بتحديد -4، تُطلب عناوين IPv4 فقط، وببتحديد -6، تُطلب عناوين IPv6 فقط.

أُضيف في الإصدار 239.

-i INTERFACE, --interface=INTERFACE

يحدد واجهة الشبكة لتنفيذ الاستعلام عليها. قد يُحدد هذا إما كفهرس واجهة رقمي أو كسلسلة واجهة شبكة (مثل "en0"). لاحظ أن هذا الخيار ليس له تأثير إذا استُخدم إعداد DNS على مستوى النظام (كما هو مهيأ في /etc/resolv.conf أو /etc/systemd/resolved.conf) بدلاً من إعداد لكل وصلة.

أُضيف في الإصدار 239.

-p PROTOCOL, --protocol=PROTOCOL

يحدد بروتوكول الشبكة للاستعلام. قد يكون واحداً من "dns" (أي DNS أحادي الإرسال الكلاسيكي)، أو "llmnr" (حل اسم البث المتعدد على الوصلة المحلية[5])، أو "llmnr-ipv4"، أو "llmnr-ipv6" (LLMNR عبر بروتوكولات IP الأساسية المشار إليها)، أو "mdns" (DNS متعدد الإرسال[6])، أو "mdns-ipv4"، أو "mdns-ipv6" (MDNS عبر بروتوكولات IP الأساسية المشار إليها). مبدئياً، يُجرى البحث عبر جميع البروتوكولات المناسبة للبحث. إذا استُخدم، يحد من مجموعة البروتوكولات التي قد تُستخدم. استخدم هذا الخيار عدة مرات لتمكين الحل عبر بروتوكولات متعددة في نفس الوقت. الإعداد "llmnr" مطابق لتحديد هذا المفتاح مرة بـ "llmnr-ipv4" ومرة بـ "llmnr-ipv6". لاحظ أن هذا الخيار لا يجبر الخدمة على حل العملية بالبروتوكول المحدد، لأن ذلك قد يتطلب واجهة شبكة وإعداداً مناسبين. قد تُستخدم القيمة الخاصة "help" لسرد القيم المعروفة.

أُضيف في الإصدار 239.

-t TYPE, --type=TYPE, -c CLASS, --class=CLASS

عند استخدامه مع أمر query، يحدد نوع سجل مورد DNS (مثل A وAAAA وMX، ...) وفئته (مثل IN وANY، ...) للبحث. إذا استُخدمت هذه الخيارات، يُطلب مجموعة سجلات مورد DNS مطابقة للفئة والنوع المحددين. الفئة المبدئية هي IN إذا حُدد نوع فقط. قد تُستخدم القيمة الخاصة "help" لسرد القيم المعروفة.

بدون هذه الخيارات، يوفر resolvectl query حلاً عالي المستوى من اسم نطاق إلى عنوان ومن عنوان إلى اسم نطاق. مع هذه الخيارات، يوفر حلاً منخفض المستوى لسجلات مورد DNS. يُوقف منطق نطاق البحث آلياً عند استخدام هذه الخيارات، أي أن أسماء النطاقات المحددة يجب أن تكون أسماء نطاقات مؤهلة بالكامل. علاوة على ذلك، تُوقف ترجمة اسم النطاق الداخلي IDNA أيضًا، أي يجب تحديد أسماء النطاقات الدولية بترميز "xn--..."، ما لم يكن البحث في MulticastDNS/LLMNR مرغوباً، وفي هذه الحالة يجب استخدام أحرف UTF-8.

أُضيف في الإصدار 239.

--service-address=BOOL

يستقبل معلمة منطقية. إذا كانت القيمة ”صحيح“ (القيمة الافتراضية)، فعند البحث عن خدمة باستخدام --service، يتم تحويل أسماء المضيفين الموجودة في سجلات الموارد SRV أيضًا.

أُضيف في الإصدار 239.

--service-txt=BOOL

يستقبل معلمة منطقية. إذا كانت القيمة true (القيمة الافتراضية)، فعند إجراء بحث عن خدمة DNS-SD باستخدام --service، سيُحل سجل بيانات تعريف الخدمة TXT أيضًا.

أُضيف في الإصدار 239.

--cname=BOOL

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (المبدئي)، تُتبع إعادة توجيهات DNS CNAME أو DNAME. وإلا، إذا تم العثور على سجل CNAME أو DNAME أثناء الحل، يُرجع خطأ.

أُضيف في الإصدار 239.

--validate=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، يُطبق التحقق من DNSSEC كالمعتاد — بشرط أن يكون ممكّنًا للشبكة ولـ systemd-resolved.service ككل. إذا كان خاطئًا، يُعطل التحقق من DNSSEC للاستعلام المحدد، بغض النظر عن تمكينه للشبكة أو في الخدمة. لاحظ أن تعيين هذا الخيار إلى صحيح لا يُجبر التحقق من DNSSEC على الأنظمة/الشبكات حيث DNSSEC مُعطل. هذا الخيار مناسب فقط لتعطيل هذا التحقق حيثما كان ممكّنًا، وليس لتمكين التحقق حيثما كان معطلًا.

أُضيف في الإصدار 248.

--synthesize=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تُحل نطاقات محددة على النظام المحلي، من بينها "localhost" و"_gateway" و"_outbound" و"_localdnsstub" و"_localdnsproxy" أو إدخالات من /etc/hosts. إذا كان خاطئًا، لا تُحل هذه النطاقات محليًا، وإما تفشل (في حالة "localhost" أو "_gateway" أو "_outbound" وما شابه) أو تذهب إلى الشبكة عبر عمليات بحث DNS/mDNS/LLMNR العادية (في حالة إدخالات /etc/hosts).

أُضيف في الإصدار 248.

--cache=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تستخدم عمليات البحث خبيئة سجل موارد DNS المحلية. إذا كان خاطئًا، تُوجه عمليات البحث إلى الشبكة بدلاً من ذلك، بغض النظر عن توفرها بالفعل في الخبيئة المحلية.

أُضيف في الإصدار 248.

--zone=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تُجاب عمليات البحث من سجلات موارد LLMNR أو mDNS المسجلة محليًا، إذا كانت محددة. إذا كان خاطئًا، لا تُؤخذ سجلات LLMNR/mDNS المسجلة محليًا في الاعتبار لطلب البحث.

أُضيف في الإصدار 248.

--trust-anchor=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تُجاب عمليات البحث عن DS وDNSKEY من مراسي الثقة DNSSEC المحلية إذا أمكن. إذا كان خاطئًا، لا يُؤخذ مخزن الثقة المحلي في الاعتبار لطلب البحث.

أُضيف في الإصدار 248.

--network=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تُجاب عمليات البحث عبر طلبات شبكة DNS أو LLMNR أو mDNS إذا لم يمكن تركيبها محليًا، أو الإجابة من الخبيئة المحلية أو النطاق أو مراسي الثقة (انظر أعلاه). إذا كان خاطئًا، لا يُجاب الطلب من الشبكة وبالتالي سيفشل إذا لم يستطع أي من المصادر المشار إليها الإجابة عليه.

أُضيف في الإصدار 248.

--search=BOOL

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (المبدئي)، يُبحث عن أي أسماء مضيف ذات تسمية واحدة محددة في النطاقات المكونة في قائمة نطاق البحث، إذا كانت غير فارغة. وإلا، يُعطل منطق نطاق البحث. لاحظ أن هذا الخيار ليس له تأثير إذا استُخدم --type= (انظر أعلاه)، وفي هذه الحالة يُطفأ منطق نطاق البحث دون شرط.

أُضيف في الإصدار 239.

--raw[=payload|packet]

يُفرغ سجلات الإجابة كبيانات ثنائية. إذا لم يكن هناك وسيط أو إذا كان الوسيط هو "payload"، يُصدر حمولة بيانات سجل المورد، أي ليس "RDATA" بالكامل، بل المحتويات الأساسية فقط. إذا كان الوسيط هو "packet"، يُفرغ سجل المورد بالكامل بتنسيق سلكي، مسبوقًا بطول محدد كعدد صحيح 64 بت صغير النهاية. يسمح هذا التنسيق بإفراغ سجلات متعددة وتحليلها دون غموض.

لاحظ أن "payload" مدعوم فقط لمجموعة فرعية صغيرة من أنواع سجلات الموارد: SSHFP وTLSA وOPENPGPKEY حيث يُفرغ هذا مادة المفتاح فقط؛ وA وAAAA حيث يُفرغ هذا بيانات العنوان.

أُضيف في الإصدار 239.

--legend=قيمة_منطقية

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (المبدئي)، تُعرض رؤوس الأعمدة والمعلومات الوصفية حول استجابة الاستعلام. وإلا، يُكبت هذا المخرج.

أُضيف في الإصدار 239.

--stale-data=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا (المبدئي)، تُجاب عمليات البحث ببيانات قديمة (سجلات موارد منتهية الصلاحية) إذا أمكن. إذا كان خاطئًا، لا تُؤخذ البيانات القديمة في الاعتبار لطلب البحث.

أُضيف في الإصدار 254.

--relax-single-label=BOOL

يأخذ معاملًا منطقيًا؛ يُستخدم مع query. إذا كان صحيحًا، تُخفف القواعد المتعلقة بتوجيه الأسماء ذات التسمية الواحدة. المبدئي خاطئ. مبدئيًا، تُفترض عمليات بحث الأسماء ذات التسمية الواحدة أنها تشير إلى مضيفين محليين ليتم حلها عبر حل محلي مثل LLMNR أو عبر تأهيل نطاق البحث ولا تُوجه إلى الخوادم العلوية كما هي. إذا كان هذا الخيار ممكّنًا، تُعطل هذه القواعد وتُوجه الاستعلامات إلى الأعلى على أي حال. انظر أيضًا خيار ResolveUnicastSingleLabel= في resolved.conf(5) الذي يوفر خيارًا على مستوى النظام يتحكم في هذا السلوك.

أُضيف في الإصدار 256.

--no-ask-password

لا تسأل المستخدم عن الاستيثاق للعمليات ذات الامتيازات.

--json=وضع

يظهر المخرجات منسقة بصيغة JSON. يتوقع أحد الخيارات: "short" (لأقصر مخرج ممكن دون أي مسافات زائدة أو فواصل أسطر)، أو "pretty" (لنسخة جميلة من المخرج نفسه، مع إزاحة وفواصل أسطر) أو "off" (لإيقاف مخرجات JSON، وهو الخيار المبدئي).

-j

يكافئ --json=pretty إذا كان يعمل على طرفية، و --json=short في الحالات الأخرى.

--no-pager

لا تمرر المخرجات إلى برنامج عرض (pager).

-h، --help

اطبع نص مساعدة قصير واخرج.

--version

اطبع سلسلة إصدار قصيرة واخرج.

التوافق مع RESOLVCONF(8)¶

resolvectl هو ثنائي متعدد الاستدعاءات. عند استدعائه كـ "resolvconf" (يُحقق عمومًا عبر رابط رمزي بهذا الاسم إلى الثنائي resolvectl) يُشغل في وضع توافق محدود مع resolvconf(8). يقبل نفس الوسائط في الغالب ويدفع جميع البيانات إلى systemd-resolved.service(8)، مشابهًا لكيفية عمل أوامر dns وdomain. لاحظ أن systemd-resolved.service هو النهاية الخلفية الوحيدة المدعومة، وهو مختلف عن التطبيقات الأخرى لهذا الأمر.

/etc/resolv.conf سيُحدث فقط بالخوادم المضافة بهذا الأمر عندما يكون /etc/resolv.conf رابطًا رمزيًا إلى /run/systemd/resolve/resolv.conf، وليس ملفًا ثابتًا. انظر مناقشة معالجة /etc/resolv.conf في systemd-resolved.service(8).

ليست كل العمليات المدعومة من قبل التطبيقات الأخرى مدعومة أصليًا. تحديدًا:

-a

يسجل بيانات تهيئة DNS لكل واجهة مع systemd-resolved. يتوقع اسم واجهة شبكة كوسيط سطر أوامر وحيد. يقرأ بيانات تهيئة DNS المتوافقة مع resolv.conf(5) من مدخله القياسي. الحقول ذات الصلة هي "nameserver" و"domain"/"search". هذا الأمر مطابق في الغالب لاستدعاء resolvectl بمزيج من أوامر dns وdomain.

أُضيف في الإصدار 239.

-d

يلغي تسجيل بيانات تهيئة DNS لكل واجهة مع systemd-resolved. هذا الأمر مطابق في الغالب لاستدعاء resolvectl revert.

أُضيف في الإصدار 239.

-f

عند التحديد، لن يشتكي -a و-d من واجهات الشبكة المفقودة وسينفذان بلا عملية في تلك الحالة بصمت.

أُضيف في الإصدار 239.

-x

هذا المفتاح لعملية "حصرية" مدعوم جزئيًا فقط. يُعيّن إلى نطاق بحث مهيأ إضافي من "~." — أي يضمن توجيه حركة DNS بشكل مفضل إلى خوادم DNS على هذه الواجهة، ما لم تكن هناك نطاقات أخرى أكثر تحديدًا مهيأة على واجهات أخرى.

أُضيف في الإصدار 239.

-p

عند التحديد، لن تُستخدم الواجهة كمسار مبدئي. انظر أيضًا systemd-resolved.service(8) حول المسار المبدئي.

أُضيف في الإصدار 257.

-m

المفتاح غير مدعوم ويُتجاهل بصمت.

أُضيف في الإصدار 239.

-u, -I, -i, -l, -R, -r, -v, -V, --enable-updates, --disable-updates, --are-updates-enabled

هذه المفاتيح غير مدعومة وسيفشل الأمر إذا استُخدمت.

أُضيف في الإصدار 239.

انظر resolvconf(8) للتفاصيل حول خيارات سطر الأوامر تلك.

أمثلة¶

مثال 1. استرداد عناوين نطاق "www.0pointer.net" (سجلات موارد A وAAAA)

$ resolvectl query www.0pointer.net
www.0pointer.net: 2a01:238:43ed:c300:10c3:bcf3:3266:da74


                  85.214.157.71
-- Information acquired via protocol DNS in 611.6ms.
-- Data is authenticated: no

مثال 2. استرداد نطاق عنوان IP "85.214.157.71" (سجل مورد PTR)

$ resolvectl query 85.214.157.71
85.214.157.71: gardel.0pointer.net
-- Information acquired via protocol DNS in 1.2997s.
-- Data is authenticated: no

مثال 3. استرداد سجل MX لنطاق "yahoo.com"

$ resolvectl --legend=no -t MX query yahoo.com
yahoo.com. IN MX    1 mta7.am0.yahoodns.net
yahoo.com. IN MX    1 mta6.am0.yahoodns.net
yahoo.com. IN MX    1 mta5.am0.yahoodns.net

مثال 4. حل خدمة SRV

$ resolvectl service _xmpp-server._tcp gmail.com
_xmpp-server._tcp/gmail.com: alt1.xmpp-server.l.google.com:5269 [priority=20, weight=0]


                             173.194.210.125


                             alt4.xmpp-server.l.google.com:5269 [priority=20, weight=0]


                             173.194.65.125


                             ...

مثال 5. استرداد مفتاح PGP (سجل مورد OPENPGP)

$ resolvectl openpgp zbyszek@fedoraproject.org
d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY


        mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlMyf


        MFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAynCsSs


        ...

مثال 6. استرداد مفتاح TLS (سجل مورد TLSA)

$ resolvectl tlsa tcp fedoraproject.org:443
_443._tcp.fedoraproject.org IN TLSA 0 0 1 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0


        -- Cert. usage: CA constraint


        -- Selector: Full Certificate


        -- Matching type: SHA-256

"tcp" و":443" اختيارية ويمكن تخطيها.