RESOLVECTL(1) resolvectl RESOLVECTL(1)

resolvectl - تفکیک نامهای دامنه، آدرسهای IPv4 و IPv6، رکوردهای DNS و کلیدها

resolvectl [OPTIONS...] {COMMAND} [NAME...]

دستور resolvectl می‌تواند برای تفکیک نام‌های دامنه، آدرس‌های IPv4 و IPv6، رکوردهای منبع DNS و سرویس‌ها از طریق سرویس تفکیک‌کننده systemd-resolved.service(8) استفاده شود. به‌طور پیشفرض، فهرست پارامترهای مشخص‌شده به عنوان نام میزبان تفکیک شده و آدرس‌های IPv4 و IPv6 آن‌ها دریافت می‌شود. اگر پارامترهای مشخص‌شده در قالب آدرس‌های IPv4 یا IPv6 باشند، عملیات معکوس انجام می‌شود و نام میزبان برای آدرس‌های مشخص‌شده واکشی می‌گردد.

خروجی برنامه شامل اطلاعاتی درباره پروتکل استفاده‌شده برای جستجو و رابط شبکه‌ای است که داده‌ها روی آن کشف شده‌اند. همچنین شامل اطلاعاتی است مبنی بر اینکه آیا داده‌ها قابل اعتبارسنجی بوده‌اند یا خیر. تمامی داده‌هایی که اعتبارسنجی محلی DNSSEC برای آن‌ها موفقیت‌آمیز باشد، معتبر (authenticated) در نظر گرفته می‌شوند. علاوه بر این، تمامی داده‌های با منشأ منابع محلی و مورد اعتماد نیز معتبر گزارش می‌شوند، از جمله تفکیک نام میزبان محلی، نام میزبان "localhost" یا تمامی داده‌های برگرفته از /etc/hosts.

query HOSTNAME|ADDRESS...

تفکیک نام‌های دامنه و همچنین آدرس‌های IPv4 و IPv6. هنگامی که در ترکیب با --type= یا --class= (به زیر مراجعه کنید) استفاده شود، رکوردهای منبع سطح پایین DNS را تفکیک می‌کند.

اگر یک نام دامنه تک‌برچسبی مشخص شود، مطابق با دامنه‌های جستجوی پیکربندی‌شده جستجو می‌شود — مگر اینکه --search=no یا --type=/--class= مشخص شده باشند، که هر دوی آن‌ها این منطق را غیرفعال می‌کنند.

اگر یک نام دامنه بین‌المللی مشخص شود، هنگام تفکیک از طریق DNS سنتی، به‌طور خودکار مطابق با قوانین IDNA ترجمه می‌شود — اما نه برای جستجوها از طریق MulticastDNS یا LLMNR. اگر از --type=/--class= استفاده شود، ترجمه IDNA خاموش شده و نام‌های دامنه همان‌گونه که مشخص شده‌اند پردازش می‌شوند.

اگر با --json= ترکیب شود (تنها در ترکیب با --type= پشتیبانی می‌شود)، داده‌های رکورد منبع را در یک شیء JSON خروجی می‌دهد.

اضافه‌شده در نسخه 239.

service [[NAME] TYPE] DOMAIN

تفکیک سرویس‌های RFC 6763 DNS-SD[1] و RFC 2782 SRV[2]، بسته به فهرست پارامترهای مشخص‌شده. اگر سه پارامتر ارسال شوند، اولی به عنوان نام سرویس DNS-SD، دومی نوع سرویس SRV و سومی دامنه مورد جستجو در نظر گرفته می‌شود. در این حالت، یک جستجوی کامل به سبک DNS-SD برای رکوردهای SRV و TXT اجرا می‌شود. اگر تنها دو پارامتر مشخص شوند، اولی به عنوان نوع سرویس SRV و دومی به عنوان دامنه مورد جستجو در نظر گرفته می‌شود. در این حالت، هیچ رکورد منبع TXT درخواست نمی‌شود. در نهایت، اگر فقط یک پارامتر مشخص شود، به عنوان نام دامنه‌ای که پیشوند نوع SRV به آن اضافه شده در نظر گرفته می‌شود و یک جستجوی SRV انجام می‌گیرد (بدون TXT).

اضافه‌شده در نسخه 239.

openpgp EMAIL@DOMAIN...

پرس‌وجوی کلیدهای PGP ذخیره‌شده به عنوان رکوردهای منبع OPENPGPKEY، به RFC 7929[3] مراجعه کنید. آدرس‌های ایمیل مشخص‌شده به نام دامنه متناظر DNS تبدیل شده و هرگونه کلید OPENPGPKEY چاپ می‌شود.

اضافه‌شده در نسخه 239.

tlsa [FAMILY] DOMAIN[:PORT]...

پرس‌وجوی کلیدهای عمومی TLS ذخیره‌شده به عنوان رکوردهای منبع TLSA، به RFC 6698[4] مراجعه کنید. یک پرس‌وجو برای هر یک از نام‌های مشخص‌شده با پیشوند درگاه و خانواده ("_port._family.domain") انجام خواهد شد. شماره درگاه می‌تواند پس از دونقطه (":") مشخص شود، در غیر این صورت به‌طور پیشفرض از 443 استفاده خواهد شد. خانواده پروتکل را می‌توان به عنوان آرگومان نخست مشخص کرد، در غیر این صورت از tcp استفاده خواهد شد.

اضافه‌شده در نسخه 239.

status [LINK...]

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

اضافه‌شده در نسخه 239.

statistics

آمار عمومی تفکیک‌کننده را نمایش می‌دهد، از جمله اطلاعاتی مبنی بر اینکه آیا DNSSEC فعال و در دسترس است یا خیر، و همچنین آمار تفکیک و اعتبارسنجی.

اضافه‌شده در نسخه 239.

reset-statistics

شمارنده‌های آماری نمایش‌داده‌شده در statistics را صفر می‌کند. این عملیات نیازمند اختیارات ریشه (root) است.

اضافه‌شده در نسخه 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

نمایش محتوای فعلی حافظه نهان، به ازای هر حوزه (scope). از --json= برای فعال‌سازی خروجی JSON استفاده کنید.

اضافه‌شده در نسخه 254.

show-server-state

نمایش اطلاعات تفصیلی وضعیت سرور، به ازای هر سرور DNS. از --json= برای فعال‌سازی خروجی JSON استفاده کنید.

اضافه‌شده در نسخه 255.

log-level [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" (Link-Local Multicast Name Resolution[5])، "llmnr-ipv4"، "llmnr-ipv6" (پروتکل LLMNR از طریق پروتکل‌های IP پایه‌ای مشخص‌شده)، "mdns" (Multicast 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 را فراهم می‌آورد. هنگام استفاده از این گزینه‌ها، منطق دامنه جستجو به‌طور خودکار غیرفعال می‌شود، بدین معنی که نام‌های دامنه مشخص‌شده باید نام‌های دامنه کاملاً واجد شرایط (FQDN) باشند. علاوه بر این، ترجمه داخلی نام دامنه بر اساس IDNA نیز خاموش می‌شود، یعنی نام‌های دامنه بین‌المللی باید با نمادگذاری "xn--..." مشخص شوند، مگر اینکه جستجو در MulticastDNS/LLMNR مد نظر باشد، که در این حالت باید از نویسه‌های UTF-8 استفاده شود.

اضافه‌شده در نسخه 239.

--service-address=BOOL

یک پارامتر بولی دریافت می‌کند. اگر درست باشد (پیشفرض)، هنگام انجام جستجوی سرویس با --service نام‌های میزبان موجود در رکوردهای منبع SRV نیز تفکیک می‌شوند.

اضافه‌شده در نسخه 239.

--service-txt=BOOL

یک پارامتر بولی دریافت می‌کند. اگر درست باشد (پیشفرض)، هنگام انجام جستجوی سرویس 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 استفاده می‌شود. اگر درست باشد (پیشفرض)، جستجوها در صورتی که نتوانند به‌طور محلی ساخته شوند، یا از حافظه نهان محلی، ناحیه (zone) یا پایه‌های اعتماد (به بالا مراجعه کنید) پاسخ داده شوند، از طریق درخواست‌های شبکه DNS، LLMNR یا mDNS پاسخ داده می‌شوند. اگر نادرست باشد، درخواست از طریق شبکه پاسخ داده نمی‌شود و بنابراین اگر هیچ‌یک از منابع ذکرشده نتوانند به آن پاسخ دهند، با شکست مواجه خواهد شد.

اضافه‌شده در نسخه 248.

--search=BOOL

یک پارامتر بولی می‌پذیرد. اگر درست باشد (پیشفرض)، هر نام میزبان تک‌برچسبی مشخص‌شده در دامنه‌های پیکربندی‌شده در فهرست دامنه‌های جستجو (در صورت خالی نبودن) جستجو خواهد شد. در غیر این صورت، منطق دامنه جستجو غیرفعال می‌شود. توجه داشته باشید که این گزینه در صورت استفاده از --type= (به بالا مراجعه کنید) هیچ تأثیری ندارد، چرا که در این حالت منطق دامنه جستجو بدون قید و شرط خاموش می‌شود.

اضافه‌شده در نسخه 239.

--raw[=payload|packet]

تخلیه رکوردهای پاسخ به صورت داده‌های باینری. اگر هیچ آرگومانی وجود نداشته باشد یا اگر آرگومان "payload" باشد، بار داده (payload) مربوط به داده‌های رکورد منبع صادر می‌شود، یعنی نه کل "RDATA"، بلکه صرفاً محتوای اصلی. اگر آرگومان "packet" باشد، کل رکورد منبع در قالب سیم (wire format) تخلیه می‌شود که طول آن به عنوان یک عدد صحیح ۶۴ بیتی little-endian پیشوند شده است. این قالب امکان تخلیه و تجزیه بدون ابهام چندین رکورد را فراهم می‌کند.

توجه داشته باشید که "payload" تنها برای زیرمجموعه کوچکی از انواع رکوردهای منبع پشتیبانی می‌شود: SSHFP، TLSA و OPENPGPKEY که در آن‌ها فقط داده‌های کلید تخلیه می‌شوند؛ و رکوردهای A و AAAA که داده‌های آدرس را تخلیه می‌کنند.

اضافه‌شده در نسخه 239.

--legend=BOOL

یک پارامتر بولی می‌گیرد. اگر درست باشد (پیشفرض)، سرایندهای ستون‌ها و اطلاعات فراداده درباره پاسخ پرس‌وجو نمایش داده می‌شوند. در غیر این صورت، این خروجی نادیده گرفته و پنهان می‌شود.

اضافه‌شده در نسخه 239.

--stale-data=BOOL

یک پارامتر بولی می‌گیرد؛ همراه با query استفاده می‌شود. اگر درست باشد (پیشفرض)، در صورت امکان به جستجوها با داده‌های بیات (رکوردهای منبع منقضی‌شده) پاسخ داده می‌شود. اگر نادرست باشد، داده‌های بیات برای درخواست جستجو در نظر گرفته نمی‌شوند.

اضافه‌شده در نسخه 254.

--relax-single-label=BOOL

یک پارامتر بولی می‌گیرد؛ در ترکیب با query استفاده می‌شود. اگر درست باشد، قوانین حاکم بر مسیریابی نام‌های تک‌برچسبی تسهیل می‌شوند. مقدار پیشفرض نادرست است. به‌طور پیشفرض، فرض بر این است که جستجوهای نام‌های تک‌برچسبی به میزبان‌های محلی اشاره دارند که باید از طریق تفکیک محلی مانند LLMNR یا صلاحیت‌سنجی از طریق دامنه جستجو تفکیک شوند و همان‌گونه که هستند به سرورهای بالادست هدایت نمی‌شوند. اگر این گزینه فعال شود، این قوانین غیرفعال شده و پرس‌وجوها در هر حال به بالادست ارسال می‌گردند. همچنین گزینه ResolveUnicastSingleLabel= را در resolved.conf(5) ببینید که یک گزینه در سطح سیستم برای کنترل این رفتار فراهم می‌کند.

اضافه‌شده در نسخه 256.

--no-ask-password

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

--json=MODE

خروجی را در قالب JSON نمایش می‌دهد. یکی از مقادیر زیر را می‌پذیرد: "short" (برای کوتاه‌ترین خروجی ممکن بدون هیچ‌گونه فاصله خالی یا خط شکسته اضافی)، "pretty" (برای نسخه‌ای خوانا و زیبا از همان داده‌ها، همراه با دندانه‌گذاری و خطوط شکسته) یا "off" (برای خاموش کردن خروجی JSON، که حالت پیشفرض است).

-j

در صورت اجرا در ترمینال، معادل --json=pretty و در غیر این صورت معادل --json=short است.

--no-pager

خروجی را به یک صفحه‌بند (pager) هدایت نمی‌کند.

-h, --help

یک متن کوتاه راهنما را چاپ کرده و خارج می‌شود.

--version

یک رشته کوتاه مربوط به نسخه برنامه را چاپ کرده و خارج می‌شود.

دستور resolvectl یک باینری چندکاره (multi-call binary) است. هنگامی که با نام "resolvconf" فراخوانی شود (که عموماً از طریق یک پیوند نمادین با این نام به فایل باینری resolvectl حاصل می‌گردد)، در یک حالت محدود سازگاری با resolvconf(8) اجرا می‌شود. این دستور بیشتر همان آرگومان‌ها را می‌پذیرد و تمام داده‌ها را به systemd-resolved.service(8) ارسال می‌کند، درست مشابه شیوه عملکرد دستورات dns و domain. توجه داشته باشید که systemd-resolved.service تنها بخش پشتیبان (backend) پشتیبانی‌شده است، که با دیگر پیاده‌سازی‌های این دستور تفاوت دارد.

فایل /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

این سوییچ برای عملیات «انحصاری» (exclusive) تنها به‌طور جزئی پشتیبانی می‌شود. این سوییچ به یک دامنه جستجوی پیکربندی‌شده اضافه از "~." نگاشت می‌شود — یعنی اطمینان می‌دهد که ترافیک 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) مراجعه کنید.

در صورت موفقیت، مقدار 0 و در غیر این صورت یک کد خطای غیرصفر بازگردانده می‌شود.

مثال ۱. واکشی آدرس‌های دامنه "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

مثال ۲. واکشی دامنه برای آدرس آی‌پی "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

مثال ۳. واکشی رکورد 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

مثال ۴. تفکیک یک سرویس 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
                             ...

مثال ۵. واکشی یک کلید PGP (رکورد منبع OPENPGP)

$ resolvectl openpgp zbyszek@fedoraproject.org
d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY
        mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlMyf
        MFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAynCsSs
        ...

مثال ۶. واکشی یک کلید 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" اختیاری هستند و می‌توان از آن‌ها صرف‌نظر کرد.

systemd(1), systemd-resolved.service(8), systemd.dnssd(5), systemd-networkd.service(8), resolvconf(8)

1.
RFC 6763 DNS-SD
https://tools.ietf.org/html/rfc6763
2.
RFC 2782 SRV
https://tools.ietf.org/html/rfc2782
3.
RFC 7929
https://tools.ietf.org/html/rfc7929
4.
RFC 6698
https://tools.ietf.org/html/rfc6698
5.
Link-Local Multicast Name Resolution
https://tools.ietf.org/html/rfc4795
6.
Multicast DNS
https://www.ietf.org/rfc/rfc6762.txt
systemd 261.2