ORG.FREEDESKTOP.RESOLVE1(5) org.freedesktop.resolve1 ORG.FREEDESKTOP.RESOLVE1(5)

org.freedesktop.resolve1 - رابط‌های گذرگاه D-Bus سرویس تحلیل نام systemd-resolved

systemd-resolved.service(8) یک سرویس سیستمی است که تحلیل و کش‌سازی نام میزبان را با استفاده از DNS، LLMNR و mDNS فراهم می‌کند. این سرویس همچنین اعتبارسنجی DNSSEC را انجام می‌دهد. این صفحه معانی تحلیل و رابط D-Bus را شرح می‌دهد.

این صفحه فقط شامل یک مرجع API است. اگر به دنبال توضیح جامع‌تری درباره چگونگی استفاده از این API هستید، لطفاً به نوشتن مدیران پیکربندی شبکه (Writing Network Configuration Managers)[1] و نوشتن کلاینت‌های تحلیل‌گر نام (Writing Resolver Clients)[2] مراجعه کنید.

این سرویس رابط‌های زیر را روی شیء Manager در گذرگاه ارائه می‌دهد:

node /org/freedesktop/resolve1 {
  interface org.freedesktop.resolve1.Manager {
    methods:
      ResolveHostname(in  i ifindex,
                      in  s name,
                      in  i family,
                      in  t flags,
                      out a(iiay) addresses,
                      out s canonical,
                      out t flags);
      ResolveAddress(in  i ifindex,
                     in  i family,
                     in  ay address,
                     in  t flags,
                     out a(is) names,
                     out t flags);
      ResolveRecord(in  i ifindex,
                    in  s name,
                    in  q class,
                    in  q type,
                    in  t flags,
                    out a(iqqay) records,
                    out t flags);
      ResolveService(in  i ifindex,
                     in  s name,
                     in  s type,
                     in  s domain,
                     in  i family,
                     in  t flags,
                     out a(qqqsa(iiay)s) srv_data,
                     out aay txt_data,
                     out s canonical_name,
                     out s canonical_type,
                     out s canonical_domain,
                     out t flags);
      GetLink(in  i ifindex,
              out o path);
      SetLinkDNS(in  i ifindex,
                 in  a(iay) addresses);
      SetLinkDNSEx(in  i ifindex,
                   in  a(iayqs) addresses);
      SetLinkDomains(in  i ifindex,
                     in  a(sb) domains);
      SetLinkDefaultRoute(in  i ifindex,
                          in  b enable);
      SetLinkLLMNR(in  i ifindex,
                   in  s mode);
      SetLinkMulticastDNS(in  i ifindex,
                          in  s mode);
      SetLinkDNSOverTLS(in  i ifindex,
                        in  s mode);
      SetLinkDNSSEC(in  i ifindex,
                    in  s mode);
      SetLinkDNSSECNegativeTrustAnchors(in  i ifindex,
                                        in  as names);
      RevertLink(in  i ifindex);
      RegisterService(in  s id,
                      in  s name_template,
                      in  s type,
                      in  q service_port,
                      in  q service_priority,
                      in  q service_weight,
                      in  aa{say} txt_datas,
                      out o service_path);
      UnregisterService(in  o service_path);
      ResetStatistics();
      FlushCaches();
      ResetServerFeatures();
    properties:
      readonly s LLMNRHostname = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s LLMNR = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s MulticastDNS = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s DNSOverTLS = '...';
      readonly a(iiay) DNS = [...];
      readonly a(iiayqs) DNSEx = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
      readonly a(iiay) FallbackDNS = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
      readonly a(iiayqs) FallbackDNSEx = [...];
      readonly (iiay) CurrentDNSServer = ...;
      readonly (iiayqs) CurrentDNSServerEx = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly a(isb) Domains = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly (tt) TransactionStatistics = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly (ttt) CacheStatistics = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s DNSSEC = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly (tttt) DNSSECStatistics = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly b DNSSECSupported = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly as DNSSECNegativeTrustAnchors = ['...', ...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s DNSStubListener = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s ResolvConfMode = '...';
  };
  interface org.freedesktop.DBus.Peer { ... };
  interface org.freedesktop.DBus.Introspectable { ... };
  interface org.freedesktop.DBus.Properties { ... };
};

متد ResolveHostname() یک نام میزبان را دریافت کرده و آن را به یک یا چند آدرس IP تحلیل می‌کند. به عنوان پارامتر، این متد نمایهٔ رابط شبکهٔ لینوکس (interface index) را برای اجرای پرس‌وجو دریافت می‌کند، یا در صورتی که اجرای آن روی هر رابط مناسبی مجاز باشد، مقدار 0 را می‌پذیرد. پارامتر name نام میزبان را برای تحلیل مشخص می‌کند. توجه داشته باشید که در صورت نیاز، تبدیل IDNA روی این نام اعمال می‌شود، مگر اینکه نام از طریق LLMNR یا MulticastDNS تحلیل شود. پارامتر family نتایج را به یک خانوادهٔ آدرس خاص محدود می‌کند. این پارامتر می‌تواند AF_INET، AF_INET6 یا AF_UNSPEC باشد. در صورتی که AF_UNSPEC مشخص شود (توصیه‌شده)، هر دو نوع آدرس، با توجه به پیکربندی شبکهٔ محلی دریافت می‌شوند (به‌عنوان مثال، اگر هیچ آدرس محلی و قابل مسیریابی IPv6 یافت نشود، هیچ آدرس IPv6 دریافت نمی‌شود؛ و به‌طور مشابه برای IPv4). یک فیلد ۶۴ بیتی flags می‌تواند برای تغییر رفتار عملیات تحلیل‌گر استفاده شود (به زیر مراجعه کنید). این متد آرایه‌ای از رکوردهای آدرس را برمی‌گرداند. هر رکورد آدرس شامل نمایهٔ رابطی است که آدرس به آن تعلق دارد، یک خانوادهٔ آدرس، و همچنین یک آرایهٔ بایت با داده‌های واقعی آدرس IP (که بسته به خانوادهٔ آدرس دارای ۴ یا ۱۶ عنصر است). خانوادهٔ آدرس بازگردانده‌شده یکی از موارد AF_INET یا AF_INET6 خواهد بود. برای IPv6، نمایهٔ رابط آدرس بازگردانده‌شده باید برای مقداردهی اولیهٔ فیلد .sin6_scope_id در یک نمونه از struct sockaddr_in6 جهت پشتیبانی از تحلیل به آدرس‌های IP پیوند-محلی (link-local) استفاده شود. به دنبال آرایهٔ آدرس، نام متعارف (canonical name) میزبان می‌آید که ممکن است با نام میزبان تحلیل‌شده یکسان باشد یا نباشد. در نهایت، یک فیلد ۶۴ بیتی flags بازگردانده می‌شود که مشابه فیلد flags ورودی تعریف شده است، اما حاوی اطلاعاتی درباره داده‌های تحلیل‌شده می‌باشد (به زیر مراجعه کنید). اگر نام میزبان ارائه‌شده یک آدرس IPv4 یا IPv6 با قالب رشته‌ای باشد، تجزیه شده و نتیجه بازگردانده می‌شود. در این حالت، هیچ ارتباط شبکه‌ای انجام نمی‌شود.

متد ResolveAddress() عملیات معکوس را اجرا می‌کند: یک آدرس IP را دریافت کرده و یک یا چند نام میزبان را برای آن به دست می‌آورد. به عنوان پارامتر، نمایهٔ رابط شبکه را برای اجرای پرس‌وجو می‌گیرد، یا اگر تمام رابط‌های مناسب قابل قبول باشند، مقدار 0 را می‌پذیرد. پارامتر family خانوادهٔ آدرس IP مورد نظر برای تحلیل را نشان می‌دهد. این پارامتر می‌تواند AF_INET یا AF_INET6 باشد. پارامتر address داده‌های خام آدرس IP را (به عنوان یک آرایهٔ بایتی ۴ یا ۱۶ بایتی) دریافت می‌کند. پارامتر ورودی flags می‌تواند برای تغییر رفتار عملیات تحلیل‌گر استفاده شود (به زیر مراجعه کنید). این متد آرایه‌ای از رکوردهای نام را بازمی‌گرداند که هر کدام شامل یک نمایهٔ رابط و یک نام میزبان است. فیلد خروجی flags شامل اطلاعات تکمیلی درباره عملیات تحلیل‌گر است (به زیر مراجعه کنید).

متد ResolveRecord() نوع، کلاس و نام رکورد منبع DNS (به اختصار RR) را دریافت کرده و مجموعهٔ کامل رکوردهای منبع (RRset)، شامل RDATA را برای آن بازیابی می‌کند. به عنوان پارامتر، نمایهٔ رابط شبکهٔ لینوکس را برای اجرای پرس‌وجو می‌گیرد، یا اگر اجرای آن روی هر رابط مناسبی مجاز باشد، مقدار 0 را می‌پذیرد. پارامتر name نام دامنهٔ RR را برای جستجو مشخص می‌کند (هیچ تبدیل IDNA اعمال نمی‌شود)، که پس از آن فیلدهای ۱۶ بیتی کلاس و نوع می‌آیند (که می‌توانند ANY باشند). در نهایت، یک فیلد flags می‌تواند برای تغییر رفتار جستجو ارسال شود (به زیر مراجعه کنید). پس از تکمیل، آرایه‌ای از آیتم‌های RR بازگردانده می‌شود. هر ورودی آرایه شامل نمایهٔ رابط شبکه‌ای است که RR روی آن کشف شده، فیلد کلاس و نوع RR یافت‌شده، و یک آرایهٔ بایت از داده‌های خام RR کشف‌شده است. داده‌های خام RR با نام دامنهٔ رکورد، با همان بزرگی و کوچکی حروف اصلی شروع می‌شود، و سپس نوع RR، کلاس، TTL و RDATA در قالب باینری مستندشده در RFC 1035[3] قرار می‌گیرد. برای رکوردهایی که از فشرده‌سازی نام در بار داده پشتیبانی می‌کنند (مانند MX یا PTR)، فشرده‌سازی در داده‌های بازگردانده‌شده باز (expand) می‌شود.

توجه داشته باشید که در حال حاضر، فیلد کلاس باید به عنوان IN یا ANY مشخص شود. تعیین یک کلاس دیگر خطایی بازمی‌گرداند که نشان می‌دهد جستجوهایی از این نوع پشتیبانی نمی‌شوند. به طور مشابه، برخی از انواع خاص نیز پشتیبانی نمی‌شوند (AXFR، OPT، و غیره). گرچه systemd-resolved رکوردهای منبع از انواع مختلف را تجزیه و اعتبارسنجی می‌کند، اما بسیار مهم است که کلاینت‌های استفاده‌کننده از این API درک کنند که داده‌های RR از شبکه سرچشمه می‌گیرند و باید پیش از استفاده به‌طور کامل اعتبارسنجی شوند.

متد ResolveService() می‌تواند برای تحلیل یک رکورد سرویس DNS از نوع SRV، و همچنین نام‌های میزبان ارجاع‌شده در آن، و احتمالاً یک رکورد همراه DNS-SD از نوع TXT حاوی فراداده‌های اضافی سرویس استفاده شود. مزیت اصلی استفاده از این متد نسبت به ResolveRecord() با مشخص کردن نوع SRV این است که رکوردهای SRV و TXT و همچنین نام‌های میزبان ارجاع‌شده در SRV را در یک عملیات واحد تحلیل می‌کند. این متد به عنوان پارامتر یک نمایهٔ رابط شبکهٔ لینوکس، یک نام سرویس، یک نوع سرویس و یک دامنهٔ سرویس را دریافت می‌کند. این متد می‌تواند در سه حالت مختلف فراخوانی شود:

1.برای تحلیل یک سرویس DNS-SD، نام سرویس (مانند "Lennart's Files")، نوع سرویس (مانند "_webdav._tcp") و دامنه‌ای که باید در آن جستجو شود (مانند "local") را به عنوان سه پارامتر سرویس مشخص کنید. نام سرویس باید در قالب UTF-8 باشد، و هیچ تبدیل IDNA در این حالت روی آن اعمال نمی‌شود (همان‌طور که مشخصات DNS-SD الزامی کرده است). با این حال، در صورت لزوم، تبدیل IDNA روی پارامتر دامنه اعمال می‌شود.
2.برای تحلیل یک رکورد سادهٔ SRV، پارامتر نام سرویس را روی یک رشتهٔ خالی قرار دهید و نوع سرویس و دامنه را به درستی تنظیم کنید. (در صورت لزوم، تبدیل IDNA روی دامنه اعمال می‌شود.)
3.در روش دیگر، هر دو پارامتر نام و نوع سرویس را خالی بگذارید و نام کامل دامنهٔ رکورد SRV (یعنی با پیشوند نوع سرویس) را در پارامتر دامنه مشخص کنید. (در این حالت هیچ تبدیل IDNA اعمال نمی‌شود.)

پارامتر family در متد ResolveService() خانوادهٔ آدرس‌های مورد نظر برای تحلیل را کدگذاری می‌کند (از AF_INET، AF_INET6، یا AF_UNSPEC استفاده کنید). در صورتی که این مورد فعال باشد (برای خاموش کردن تحلیل آدرس، از پرچم NO_ADDRESS استفاده کنید، به زیر مراجعه شود). پارامتر flags چندین پرچم را می‌پذیرد که می‌توانند برای تغییر عملکرد عملیات تحلیل‌گر استفاده شوند.

پس از تکمیل، ResolveService() آرایه‌ای از ساختارهای رکورد SRV را بازمی‌گرداند. هر آیتم شامل فیلدهای اولویت، وزن و درگاه و همچنین نام میزبان برای اتصال است، همان‌طور که در رکورد SRV کدگذاری شده است. بلافاصله پس از آن، آرایه‌ای از آدرس‌های این نام میزبان قرار دارد، که هر آیتم شامل نمایهٔ رابط، خانوادهٔ آدرس و داده‌های آدرس در یک آرایهٔ بایت است. به دنبال این آرایهٔ آدرس، نام میزبان متعارف‌شده می‌آید. پس از این آرایه از ساختارهای رکورد SRV، آرایه‌ای از آرایه‌های بایت می‌آید که رشته‌های RR از نوع TXT را کدگذاری می‌کند، در صورتی که جستجوهای DNS-SD فعال باشند. پارامترهای بعدی نام، نوع و دامنهٔ متعارف سرویس هستند. این مقادیر ممکن است با پارامترهای ارسالی یکسان باشند یا نباشند. در نهایت، یک فیلد flags بازگردانده می‌شود که حاوی اطلاعاتی درباره عملیات تحلیل‌گر انجام‌شده است.

متد ResetStatistics() شمارنده‌های آماری گوناگونی را که systemd-resolved نگهداری می‌کند به صفر بازنشانی می‌نماید. (برای جزئیات، به ویژگی‌های آماری در زیر مراجعه کنید.)

متد GetLink() یک نمایهٔ رابط شبکه را می‌گیرد و مسیر شیء مربوط به شیء org.freedesktop.resolve1.Link متناظر با آن را برمی‌گرداند.

متد SetLinkDNS() سرورهای DNS را برای استفاده در یک رابط خاص تنظیم می‌کند. این متد (و متدهای بعدی) می‌توانند توسط نرم‌افزارهای مدیریت شبکه برای پیکربندی تنظیمات DNS به ازای هر رابط استفاده شوند. این متد یک نمایهٔ رابط شبکه و همچنین آرایه‌ای از رکوردهای آدرس IP سرورهای DNS را دریافت می‌کند. هر آیتم آرایه شامل یک خانوادهٔ آدرس (یا AF_INET یا AF_INET6) و به دنبال آن یک آرایهٔ ۴ بایتی یا ۱۶ بایتی با داده‌های خام آدرس است. این متد یک میان‌بر تک‌مرحله‌ای برای بازیابی شیء Link برای یک رابط شبکه با استفاده از GetLink() (به بالا مراجعه کنید) و سپس فراخوانی متد SetDNS() (به زیر مراجعه کنید) روی آن است.

متد SetLinkDNSEx() مشابه SetLinkDNS() است، اما اجازه می‌دهد یک درگاه IP (به جای درگاه پیش‌فرض ۵۳) و نام DNS برای هر سرور DNS مشخص شود. نام سرور برای نشان‌گذاری نام سرور (SNI) استفاده می‌شود که هنگام استفاده از DNS-over-TLS مفید است. مقایسه کنید با DNS= در resolved.conf(5).

متد SetLinkDefaultRoute() مشخص می‌کند که آیا این پیوند باید به عنوان مسیر پیش‌فرض برای پرس‌وجوهای نام استفاده شود یا خیر. برای جزئیات، توضیحات مسیریابی نام را در systemd-resolved.service(8) ببینید.

متد SetLinkDomains() دامنه‌های جستجو و مسیریابی را برای استفاده در یک رابط شبکهٔ خاص جهت جستجوهای DNS تنظیم می‌کند. این متد نمایهٔ رابط شبکه و آرایه‌ای از دامنه‌ها را دریافت می‌کند، که هر کدام دارای یک پارامتر بولی هستند که نشان می‌دهد آیا دامنهٔ مشخص‌شده باید به عنوان دامنهٔ جستجو استفاده شود (false)، یا فقط به عنوان دامنهٔ مسیریابی (true). دامنه‌های جستجو برای تکمیل نام‌های تک‌بخشی به FQDN هنگام جستجوی نام‌های میزبان، و همچنین برای تصمیم‌گیری‌های مسیریابی در مورد اینکه پرس‌وجوهای ختم‌شده به آن دامنه به کدام رابط ارسال شوند، استفاده می‌شوند. دامنه‌های مسیریابی فقط برای تصمیم‌گیری‌های مسیریابی استفاده می‌شوند و برای صلاحیت‌سنجی نام‌های تک‌بخشی به کار نمی‌روند. دامنه‌های جستجو را به ترتیبی که باید استفاده شوند ارسال کنید.

متد SetLinkLLMNR() پشتیبانی از LLMNR را روی یک رابط شبکهٔ خاص فعال یا غیرفعال می‌کند. این متد یک نمایهٔ رابط شبکه و همچنین یک رشته را دریافت می‌کند که می‌تواند خالی یا یکی از مقادیر "yes"، "no" یا "resolve" باشد. در صورت خالی بودن، از تنظیم پیش‌فرض سراسری systemd برای LLMNR استفاده می‌شود. در صورت انتخاب "yes"، از LLMNR برای تحلیل نام‌های تک‌بخشی استفاده می‌شود و نام میزبان محلی در تمام LANهای محلی برای تحلیل LLMNR توسط همتایان ثبت می‌گردد. در صورت انتخاب "no"، پروتکل LLMNR به طور کامل روی این رابط خاموش می‌شود. در صورت انتخاب "resolve"، پروتکل LLMNR تنها برای تحلیل نام‌ها فعال می‌شود، اما نام میزبان محلی برای استفاده توسط سایر همتایان ثبت نخواهد شد.

به طور مشابه، متد SetLinkMulticastDNS() پشتیبانی از MulticastDNS را روی یک رابط خاص فعال یا غیرفعال می‌کند. این متد همان پارامترهای SetLinkLLMNR() توصیف‌شده در بالا را می‌پذیرد.

متد SetLinkDNSSEC() اعتبارسنجی DNSSEC را روی یک رابط شبکهٔ خاص فعال یا غیرفعال می‌کند. این متد یک نمایهٔ رابط شبکه و همچنین یک رشته را دریافت می‌کند که می‌تواند خالی یا یکی از مقادیر "yes"، "no" یا "allow-downgrade" باشد. در صورت خالی بودن، از تنظیم پیش‌فرض سراسری سیستم برای DNSSEC استفاده می‌شود. در صورت انتخاب "yes"، اعتبارسنجی کامل DNSSEC برای تمام جستجوها انجام می‌شود. اگر سرور DNS انتخاب‌شده از DNSSEC پشتیبانی نکند، جستجوها در صورت استفاده از این حالت با شکست مواجه خواهند شد. در صورت انتخاب "no"، اعتبارسنجی DNSSEC به‌طور کامل غیرفعال می‌شود. در صورت انتخاب "allow-downgrade"، اعتبارسنجی DNSSEC فعال می‌شود، اما اگر سرور انتخاب‌شده از آن پشتیبانی نکند به طور خودکار خاموش می‌گردد (که رفتار را در معرض حملات کاهش سطح یا downgrade قرار می‌دهد). توجه داشته باشید که DNSSEC فقط برای DNS سنتی اعمال می‌شود، نه برای LLMNR یا MulticastDNS.

متد SetLinkDNSSECNegativeTrustAnchors() می‌تواند برای پیکربندی لنگرهای اعتماد منفی DNSSEC (یا NTAs) برای یک رابط شبکهٔ خاص استفاده شود. این متد یک نمایهٔ رابط شبکه و فهرستی از دامنه‌ها را به عنوان آرگومان دریافت می‌کند.

متد SetLinkDNSOverTLS() قابلیت DNS-over-TLS را فعال یا غیرفعال می‌کند. برای جزئیات، مقایسه کنید با DNSOverTLS= در systemd-resolved.service(8).

نرم‌افزارهای مدیریت شبکه که با systemd-resolved یکپارچه می‌شوند باید SetLinkDNS() یا SetLinkDNSEx()، SetLinkDefaultRoute()، SetLinkDomains() و سایر متدها را پس از ظاهر شدن رابط در هسته (و در نتیجه پس از تخصیص نمایهٔ رابط شبکه)، اما قبل از فعال شدن رابط شبکه (تنظیم شدن IFF_UP) فراخوانی کنند تا تمام تنظیمات در تمام مدتی که رابط شبکه بالا (up) است اعمال شوند. با این حال، تغییر تنظیمات در زمان فعال بودن رابط نیز ایمن است. از RevertLink() (شرح داده شده در زیر) برای بازنشانی تمام تنظیمات مربوط به هر رابط استفاده کنید.

متد RevertLink() می‌تواند برای بازگرداندن تمام تنظیمات مربوط به هر پیوند که در بالا شرح داده شد به مقادیر پیش‌فرض استفاده شود.

متد FlushCaches() تمام کش‌های رکورد منبع نگهداری‌شده توسط تحلیل‌گر را پاکسازی می‌کند و تضمین می‌نماید که هرگونه جستجوی بعدی مجدداً پاسخ‌های خود را از منابع مربوطه‌شان درخواست کند.

متد ResetServerFeatures() هرگونه اطلاعات ویژگی‌های آموخته‌شده درباره سرورهای دوردست DNS را پاکسازی می‌کند. این امر اطمینان می‌دهد که جستجوهای بعدی در ابتدا دوباره در بالاترین سطح ویژگی پروتکل DNS تلاش شوند، که احتمالاً نیاز به یک چرخهٔ کاهش سطح (که بالقوه کند است) برای تشخیص مجدد سطح ویژگی پشتیبانی‌شده دارد.

متد RegisterService() می‌تواند برای ثبت یک سرویس DNS-SD روی میزبان استفاده شود. این قابلیت ارتباط نزدیکی با قابلیت ارائه‌شده توسط فایل‌های systemd.dnssd(5) دارد. این متد یک رشتهٔ شناسهٔ سرور را به عنوان اولین پارامتر دریافت می‌کند (این فقط یک شناسهٔ محلی است، و باید طوری انتخاب شود که نه با نام پایهٔ فایل‌های *.dnssd و نه با نام‌های انتخاب‌شده توسط سایر کلاینت‌های IPC تداخل داشته باشد). همچنین یک رشتهٔ الگوی نام برای نام سرویس DNS-SD قابل مشاهده در شبکه دریافت می‌کند. این رشته تحت تأثیر بسط مشخص‌کننده‌ها (specifier expansion) قرار می‌گیرد، همان‌طور که برای تنظیم Name= در فایل‌های *.dnssd مستند شده است. این متد همچنین یک رشتهٔ نوع سرویس حاوی نوع سرویس DNS-SD و همچنین یک درگاه IP، و یک جفت اولویت/وزن برای رکورد DNS-SD SRV دریافت می‌کند. در نهایت، آرایه‌ای از داده‌های رکورد TXT را می‌گیرد. این متد یک مسیر شیء را برمی‌گرداند که می‌تواند به عنوان دستگیره برای سرویس ثبت‌شده استفاده شود.

متد UnregisterService() اثر RegisterService() را خنثی کرده و یک سرویس DNS-SD را که قبلاً از طریق IPC ایجاد شده بود، دوباره حذف می‌کند.

پارامتر پرچم‌ها (The Flags Parameter)

چهار متد بالا یک مقدار پرچم ۶۴ بیتی را می‌پذیرند و بازمی‌گردانند. در بیشتر موارد ارسال مقدار 0 کافی و توصیه‌شده است. با این حال، پرچم‌های زیر برای تغییر رفتار جستجو تعریف شده‌اند:

/* ورودی+خروجی: پروتکل/دامنه */
#define SD_RESOLVED_DNS                (UINT64_C(1) <<  0)
#define SD_RESOLVED_LLMNR_IPV4         (UINT64_C(1) <<  1)
#define SD_RESOLVED_LLMNR_IPV6         (UINT64_C(1) <<  2)
#define SD_RESOLVED_MDNS_IPV4          (UINT64_C(1) <<  3)
#define SD_RESOLVED_MDNS_IPV6          (UINT64_C(1) <<  4)
/* ورودی: محدودیت‌ها */
#define SD_RESOLVED_NO_CNAME           (UINT64_C(1) <<  5)
#define SD_RESOLVED_NO_TXT             (UINT64_C(1) <<  6)
#define SD_RESOLVED_NO_ADDRESS         (UINT64_C(1) <<  7)
#define SD_RESOLVED_NO_SEARCH          (UINT64_C(1) <<  8)
#define SD_RESOLVED_NO_VALIDATE        (UINT64_C(1) << 10)
#define SD_RESOLVED_NO_SYNTHESIZE      (UINT64_C(1) << 11)
#define SD_RESOLVED_NO_CACHE           (UINT64_C(1) << 12)
#define SD_RESOLVED_NO_ZONE            (UINT64_C(1) << 13)
#define SD_RESOLVED_NO_TRUST_ANCHOR    (UINT64_C(1) << 14)
#define SD_RESOLVED_NO_NETWORK         (UINT64_C(1) << 15)
#define SD_RESOLVED_NO_STALE           (UINT64_C(1) << 24)
#define SD_RESOLVED_RELAX_SINGLE_LABEL (UINT64_C(1) << 25)
/* خروجی: امنیت */
#define SD_RESOLVED_AUTHENTICATED      (UINT64_C(1) <<  9)
#define SD_RESOLVED_CONFIDENTIAL       (UINT64_C(1) << 18)
/* خروجی: مبدأ */
#define SD_RESOLVED_SYNTHETIC          (UINT64_C(1) << 19)
#define SD_RESOLVED_FROM_CACHE         (UINT64_C(1) << 20)
#define SD_RESOLVED_FROM_ZONE          (UINT64_C(1) << 21)
#define SD_RESOLVED_FROM_TRUST_ANCHOR  (UINT64_C(1) << 22)
#define SD_RESOLVED_FROM_NETWORK       (UINT64_C(1) << 23)

در ورودی، پنج پرچم نخست پروتکل‌های مورد استفاده برای جستجو را کنترل می‌کنند. این پرچم‌ها به ترتیب به DNS تک‌پخشی (unicast) کلاسیک، LLMNR از طریق IPv4/UDP و IPv6/UDP، و همچنین MulticastDNS از طریق IPv4/UDP و IPv6/UDP اشاره دارند. اگر تمام این پنج بیت در ورودی خاموش (off) باشند (که اکیداً توصیه می‌شود)، جستجو از طریق تمام پروتکل‌های مناسب برای آن جستجوی خاص انجام خواهد شد. توجه داشته باشید که این پرچم‌ها فقط به عنوان فیلتر عمل می‌کنند و نمی‌توانند انجام یک جستجو را از طریق یک پروتکل اجبار کنند. به‌طور مشخص، systemd-resolved فقط پرس‌وجوهای درون دامنهٔ سطح‌بالای (TLD) .local را به MulticastDNS هدایت می‌کند (به علاوه برخی دامنه‌های آدرس جستجوی معکوس)، و نام‌های تک‌بخشی را به LLMNR (به علاوه برخی دامنه‌های جستجوی معکوس آدرس) هدایت می‌نماید. هیچ‌یک از این موارد را به سرورهای DNS تک‌پخشی هدایت نخواهد کرد. همچنین، LLMNR و Multicast DNS را تنها روی رابط‌هایی انجام می‌دهد که برای چندپخشی (multicast) مناسب باشند.

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

کاربرد اصلی این پنج پرچم برای جستجوهای تکمیلی بر اساس داده‌های DNS دریافت‌شده در مراحل قبلی است. در این حالت، اغلب ایدهٔ خوبی است که جستجوی تکمیلی را به پروتکلی محدود کنید که برای کشف اولین نتیجهٔ DNS استفاده شده بود.

پرچم NO_CNAME کنترل می‌کند که آیا رکوردهای منبع CNAME/DNAME در حین جستجو باید دنبال شوند یا خیر. این پرچم فقط در ورودی در دسترس است، و هیچ‌یک از توابع آن را در خروجی بازنمی‌گردانند. اگر در حین تحلیل یک نام میزبان یک رکورد CNAME/DNAME کشف شود، به جای آن یک خطا برگردانده می‌شود. به طور پیش‌فرض، زمانی که این پرچم خاموش است، رکوردهای CNAME/DNAME دنبال می‌شوند.

پرچم‌های NO_TXT و NO_ADDRESS تنها بر عملکرد متد ResolveService() تأثیر می‌گذارند. این پرچم‌ها فقط برای ورودی تعریف شده‌اند، نه خروجی. اگر NO_TXT تنظیم شده باشد، جستجوی رکورد DNS-SD TXT RR در همان عملیات انجام نمی‌شود. اگر NO_ADDRESS تنظیم شده باشد، نام‌های میزبان کشف‌شده به‌طور ضمنی به آدرس‌های خود ترجمه نمی‌شوند.

پرچم NO_SEARCH منطق دامنهٔ جستجو (search domain) را غیرفعال می‌کند. این پرچم تنها برای ورودی در ResolveHostname() تعریف شده است. هنگام تعیین این پرچم، نام‌های میزبان تک‌بخشی با استفاده از دامنه‌های جستجوی تعریف‌شده (در صورت وجود) صلاحیت‌سنجی نمی‌شوند. توجه داشته باشید که ResolveRecord() هرگز نام‌های دامنهٔ تک‌بخشی را با استفاده از دامنه‌های جستجو تکمیل نمی‌کند. همچنین توجه داشته باشید که نام‌های میزبان چندبخشی هرگز مشمول بسط لیست جستجو نمی‌شوند.

پرچم NO_VALIDATE می‌تواند برای غیرفعال کردن اعتبارسنجی از طریق DNSSEC تنظیم شود، حتی اگر در حالت عادی از آن استفاده می‌شد.

شش پرچم بعدی امکان غیرفعال کردن منابع خاصی را در طول فرایند تحلیل فراهم می‌کنند. پرچم NO_SYNTHESIZE رکوردهای مصنوعی (مانند نام میزبان محلی) را غیرفعال می‌کند؛ برای اطلاعات بیشتر بخش SYNTHETIC RECORDS را در systemd-resolved.service(8) ببینید. پرچم NO_CACHE استفاده از کش رکوردهای تحلیل‌شدهٔ قبلی را غیرفعال می‌کند. پرچم NO_ZONE پاسخ‌ها با استفاده از رکوردهای منبع عمومی LLMNR/mDNS ثبت‌شده به‌صورت محلی را غیرفعال می‌نماید. پرچم NO_TRUST_ANCHOR پاسخ‌ها با استفاده از لنگرهای اعتماد پیکربندی‌شده به‌صورت محلی را غیرفعال می‌کند. پرچم NO_NETWORK الزامی می‌کند که تمام پاسخ‌ها بدون استفاده از شبکه، یعنی یا از منابع محلی یا از کش ارائه شوند. پرچم NO_STALE می‌تواند برای جلوگیری از پاسخ دادن به درخواست با رکوردهای منقضی‌شده تنظیم شود.

بیت AUTHENTICATED تنها در پرچم‌های خروجی این چهار تابع تعریف شده است. اگر تنظیم شده باشد، داده‌های بازگردانده‌شده کاملاً احراز هویت و اعتبارسنجی شده‌اند. به‌طور مشخص، این بیت برای تمام داده‌های محافظت‌شده با DNSSEC تنظیم می‌شود که یک زنجیرهٔ اعتماد کامل برای آن‌ها به یک لنگر دامنهٔ مورد اعتماد ایجاد شده باشد. همچنین برای داده‌های سنتز‌شده به‌صورت محلی، مانند "localhost" یا داده‌های برگرفته از /etc/hosts تنظیم می‌گردد. علاوه بر این، برای تمام رکوردهای LLMNR یا mDNS که از میزبان محلی سرچشمه می‌گیرند نیز تنظیم می‌شود. برنامه‌هایی که برای عملکرد خود به داده‌های معتبر و احرازشدهٔ RR نیاز دارند، باید این پرچم را قبل از اعتماد به داده‌ها بررسی کنند. توجه داشته باشید که systemd-resolved هرگز داده‌های بی‌اعتبارشده را بازنمی‌گرداند، بنابراین این پرچم صرفاً به فرد امکان می‌دهد مواردی را که داده‌ها معتبر و قابل اعتماد شناخته می‌شوند، از مواردی که شواهدی مبنی بر احراز نشدن «به‌حق» داده‌ها وجود دارد (که شامل مواردی است که پروتکل یا سرور زیربنایی از احراز هویت داده‌ها پشتیبانی نمی‌کند) تشخیص دهد.

پرچم CONFIDENTIAL به این معنی است که پرس‌وجو از طریق کانال‌های رمزگذاری‌شده تحلیل شده یا هرگز از این سیستم خارج نشده است.

پنج پرچم بیتی بعدی در خروجی استفاده می‌شوند و اطلاعاتی درباره منشأ و مبدأ پاسخ ارائه می‌دهند. مقدار FROM_SYNTHETIC به این معنی است که پرس‌وجو (حداقل به‌طور جزئی) به‌صورت محلی سنتز شده است. مقدار FROM_CACHE به این معنی است که به پرس‌وجو (حداقل به‌طور جزئی) با استفاده از حافظهٔ کش پاسخ داده شده است. مقدار FROM_ZONE به این معنی است که به پرس‌وجو (حداقل به‌طور جزئی) بر اساس رکوردهای عمومی ثبت‌شدهٔ محلی پاسخ داده شده است. مقدار FROM_TRUST_ANCHOR به این معنی است که به پرس‌وجو (حداقل به‌طور جزئی) با استفاده از لنگرهای اعتماد محلی پاسخ داده شده است. مقدار FROM_NETWORK به این معنی است که به پرس‌وجو (حداقل به‌طور جزئی) با استفاده از شبکه پاسخ داده شده است.

ویژگی‌های LLMNR و MulticastDNS گزارش می‌دهند که آیا LLMNR و MulticastDNS (به‌صورت سراسری) فعال هستند یا خیر. هر کدام می‌توانند یکی از مقادیر "yes"، "no" و "resolve" باشند. به SetLinkLLMNR() و SetLinkMulticastDNS() در بالا مراجعه کنید.

ویژگی LLMNRHostname شامل نام میزبانی است که در حال حاضر از طریق LLMNR در شبکه در معرض دید قرار دارد. این مقدار معمولاً از نام میزبان سیستم پیروی می‌کند همان‌طور که ممکن است از طریق gethostname(3) پرس‌وجو شود، اما اگر تداخلی در شبکه شناسایی شود ممکن است تفاوت داشته باشد.

ویژگی‌های DNS و DNSEx شامل آرایه‌هایی از تمام سرورهای DNS هستند که در حال حاضر توسط systemd-resolved استفاده می‌شوند. DNS حاوی اطلاعاتی مشابه داده‌های سرور DNS در /run/systemd/resolve/resolv.conf است. هر ساختار در این آرایه شامل یک نمایهٔ عددی رابط شبکه، یک خانوادهٔ آدرس، و یک آرایهٔ بایت حاوی آدرس سرور DNS است (با طول ۴ بایت برای IPv4 یا ۱۶ بایت برای IPv6). DNSEx مشابه است، اما علاوه بر این شامل درگاه IP و نام سرور (مورد استفاده برای نشان‌گذاری نام سرور، SNI) می‌باشد. هر دو آرایه حاوی سرورهای DNS پیکربندی‌شده در سطح سیستم هستند، از جمله مواردی که احتمالاً از یک /etc/resolv.conf خارجی خوانده شده‌اند یا در تنظیم DNS= در /etc/systemd/resolved.conf تعیین شده‌اند، و همچنین شامل اطلاعات سرور DNS به ازای هر رابط که از systemd-networkd(8) دریافت شده یا توسط نرم‌افزار خارجی از طریق SetLinkDNS() یا SetLinkDNSEx() (به بالا مراجعه کنید) پیکربندی شده است. نمایهٔ رابط شبکه برای سرویس‌های پیکربندی‌شده در سطح سیستم مقدار 0 و برای سرورهای به ازای هر پیوند غیر صفر خواهد بود.

ویژگی‌های FallbackDNS و FallbackDNSEx شامل آرایه‌هایی از تمام سرورهای DNS هستند که در صورت وجود به عنوان سرورهای پشتیبان پیکربندی شده‌اند، با استفاده از همان ساختاری که برای DNS و DNSEx در بالا شرح داده شد. برای آگاهی از زمان استفاده از این سرورها، توضیحات FallbackDNS= را در resolved.conf(5) ببینید.

ویژگی‌های CurrentDNSServer و CurrentDNSServerEx سروری را مشخص می‌کنند که در حال حاضر برای تحلیل پرس‌وجو استفاده می‌شود، با همان ساختاری که برای یک ورودی منفرد در آرایه‌های DNS و DNSEx در بالا توصیف شد.

به طور مشابه، ویژگی Domains شامل آرایه‌ای از تمام دامنه‌های جستجو و مسیریابی است که در حال حاضر توسط systemd-resolved استفاده می‌شوند. هر ورودی شامل یک نمایهٔ رابط شبکه (باز هم مقدار 0 ورودی‌های سراسری سیستم را کدگذاری می‌کند)، نام واقعی دامنه، و اینکه آیا ورودی فقط برای مسیریابی استفاده می‌شود (true) یا هم برای مسیریابی و هم برای جستجو (false) می‌باشد.

ویژگی TransactionStatistics شامل اطلاعاتی درباره تعداد تراکنش‌هایی است که systemd-resolved پردازش کرده است. این ویژگی شامل یک جفت شمارندهٔ ۶۴ بیتی بدون علامت است که اولی شامل تعداد تراکنش‌های جاری و در حال اجرا، و دومی تعداد کل تراکنش‌هایی است که systemd-resolved در حال پردازش آن‌هاست یا پردازش کرده است. مقدار دوم می‌تواند با استفاده از متد ResetStatistics() که در بالا شرح داده شد، بازنشانی شود. توجه داشته باشید که تعداد تراکنش‌ها مستقیماً با تعداد فراخوانی‌های متد گذرگاه تحلیل‌گر صادرشده تطابق ندارد. در حالی که جستجوهای ساده معمولاً فقط به یک تراکنش منفرد نیاز دارند، جستجوهای پیچیده‌تر ممکن است به موارد بیشتری منجر شوند، برای مثال هنگامی که CNAMEها یا DNSSEC در حال استفاده هستند.

ویژگی CacheStatistics حاوی اطلاعاتی درباره عملیات کش اجراشده تا این لحظه است. این ویژگی سه شمارندهٔ ۶۴ بیتی را ارائه می‌دهد: اولی تعداد کل ورودی‌های فعلی کش (اعم از مثبت و منفی)، دومی تعداد دفعات اصابت کش (cache hits)، و سومی تعداد دفعات عدم اصابت کش (cache misses). دو شمارندهٔ آخر می‌توانند با استفاده از ResetStatistics() (به بالا مراجعه کنید) بازنشانی شوند.

ویژگی DNSSEC وضعیت فعلی اعتبارسنجی DNSSEC را مشخص می‌کند. این مقدار یکی از موارد "yes" (اعتبارسنجی اجباری است)، "no" (هیچ اعتبارسنجی انجام نمی‌شود)، "allow-downgrade" (در صورتی که سرور DNS فعلی از آن پشتیبانی کند اعتبارسنجی انجام می‌شود) است. توضیحات DNSSEC= در resolved.conf(5) را ببینید.

ویژگی DNSSECStatistics حاوی اطلاعاتی درباره اعتبارسنجی‌های DNSSEC اجراشده تا کنون است. این ویژگی شامل چهار شمارندهٔ ۶۴ بیتی است: تعداد اعتبارسنجی‌های امن (secure)، ناامن (insecure)، جعلی (bogus)، و نامعین (indeterminate) در DNSSEC تا این لحظه. این شمارنده‌ها برای هر RRset اعتبارسنجی‌شده، و هر اثبات عدم وجود افزایش می‌یابند. شمارندهٔ secure برای هر عملیاتی که با موفقیت یک پاسخ امضاشده را تأیید کند افزایش می‌یابد؛ شمارندهٔ insecure برای هر عملیاتی که با موفقیت تأیید کند که یک پاسخ بدون امضا به‌حق بدون امضا است افزایش می‌یابد؛ شمارندهٔ bogus برای هر عملیاتی افزایش می‌یابد که اعتبارسنجی در آن تطابق نیافته و احتمالاً داده‌ها دستکاری شده‌اند. در نهایت، شمارندهٔ indeterminate برای هر عملیاتی افزایش می‌یابد که به دلیل در دسترس نبودن کلیدهای لازم یا ناشناخته بودن الگوریتم‌های رمزنگاری کامل نشده است.

ویژگی بولی DNSSECSupported گزارش می‌دهد که آیا DNSSEC فعال است و آیا سرورهای DNS انتخاب‌شده از آن پشتیبانی می‌کنند یا خیر. این ویژگی اطلاعات مربوط به تنظیمات DNS سراسری سیستم و به ازای هر پیوند (به زیر مراجعه کنید) را ترکیب می‌کند، و تنها در صورتی true را گزارش می‌دهد که DNSSEC در هر رابطی که DNS برای آن پیکربندی شده و برای تنظیمات سراسری سیستم (در صورت وجود) فعال بوده و پشتیبانی شود. توجه داشته باشید که systemd-resolved فرض می‌کند DNSSEC توسط سرورهای DNS پشتیبانی می‌شود مگر اینکه تأیید کند چنین نیست. بنابراین، مقدار گزارش‌شده ممکن است در ابتدا true باشد تا زمانی که اولین تراکنش‌ها اجرا شوند.

ویژگی بولی DNSOverTLS گزارش می‌دهد که آیا DNS-over-TLS فعال است یا خیر.

ویژگی ResolvConfMode نحوهٔ مدیریت /etc/resolv.conf روی میزبان را نشان می‌دهد. در حال حاضر، مقادیر ممکن عبارتند از "uplink"، "stub"، "static" (این سه مورد با سه فایل مختلف ارائه‌شده توسط systemd-resolved.service مطابقت دارند)، "foreign" (فایل توسط مدیر سیستم یا سرویس دیگری مدیریت می‌شود، و systemd-resolved.service تنها آن را مصرف می‌کند)، "missing" (فایل /etc/resolv.conf وجود ندارد).

ویژگی DNSStubListener گزارش می‌دهد که آیا شنوندهٔ خرد (stub listener) روی درگاه ۵۳ فعال است یا خیر. مقادیر ممکن عبارتند از "yes" (فعال)، "no" (غیرفعال)، "udp" (تنها شنوندهٔ UDP فعال است)، و "tcp" (تنها شنوندهٔ TCP فعال است).

ویژگی DNSSECNegativeTrustAnchors حاوی فهرستی از لنگرهای اعتماد منفی DNSSEC شناخته‌شده است و فهرستی از دامنه‌ها را در بر دارد.

node /org/freedesktop/resolve1/link/_1 {
  interface org.freedesktop.resolve1.Link {
    methods:
      SetDNS(in  a(iay) addresses);
      SetDNSEx(in  a(iayqs) addresses);
      SetDomains(in  a(sb) domains);
      SetDefaultRoute(in  b enable);
      SetLLMNR(in  s mode);
      SetMulticastDNS(in  s mode);
      SetDNSOverTLS(in  s mode);
      SetDNSSEC(in  s mode);
      SetDNSSECNegativeTrustAnchors(in  as names);
      Revert();
    properties:
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly t ScopesMask = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly a(iay) DNS = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly a(iayqs) DNSEx = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly (iay) CurrentDNSServer = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly (iayqs) CurrentDNSServerEx = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly a(sb) Domains = [...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly b DefaultRoute = ...;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s LLMNR = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s MulticastDNS = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s DNSOverTLS = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly s DNSSEC = '...';
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly as DNSSECNegativeTrustAnchors = ['...', ...];
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly b DNSSECSupported = ...;
  };
  interface org.freedesktop.DBus.Peer { ... };
  interface org.freedesktop.DBus.Introspectable { ... };
  interface org.freedesktop.DBus.Properties { ... };
};

برای هر رابط شبکهٔ لینوکس یک شیء «Link» ایجاد می‌شود که پیکربندی و وضعیت DNS مربوط به آن پیوند را ارائه می‌دهد. از GetLink() روی رابط Manager برای بازیابی مسیر شیء مربوط به یک شیء پیوند با داشتن نمایهٔ رابط شبکه (به بالا مراجعه کنید) استفاده نمایید.

متدهای مختلف ارائه‌شده توسط رابط Link معادل همتایان هم‌نام خود در رابط Manager هستند؛ برای مثال SetDNS() روی شیء Link به SetLinkDNS() روی شیء Manager نگاشت می‌شود، با این تفاوت اصلی که دومی انتظار دارد یک نمایهٔ رابط مشخص شود. فراخوانی متدها روی رابط Manager این مزیت را دارد که رفت‌وبرگشت‌ها (roundtrips) را کاهش می‌دهد، زیرا نیازی به درخواست اولیهٔ مسیر شیء Link از طریق GetLink() پیش از فراخوانی متدها نیست. همین رابطه برای SetDNSEx()، SetDomains()، SetDefaultRoute()، SetLLMNR()، SetMulticastDNS()، SetDNSOverTLS()، SetDNSSEC()، SetDNSSECNegativeTrustAnchors()، و Revert() نیز برقرار است. برای جزئیات بیشتر درباره این متدها، مستندات Manager در بالا را ببینید.

ویژگی ScopesMask تعریف می‌کند که کدام حوزه‌های تحلیل‌گر در حال حاضر روی این رابط فعال هستند. این فیلد عددی ۶۴ بیتی بدون علامت، یک ماسک بیتی متشکل از زیرمجموعه‌ای از بیت‌های پارامتر flags توصیف‌شده در بالا است. به‌طور مشخص، ممکن است بیت‌های DNS، LLMNR و MDNS (اولی در دو حالت IPv4 و IPv6) در آن تنظیم شده باشند. هر بیت منفرد زمانی تنظیم می‌شود که پروتکل برای یک رابط خاص اعمال شود و برای آن فعال باشد؛ در غیر این صورت تنظیم نشده است. به‌طور مشخص، یک رابط با قابلیت چندپخشی (multicast) در وضعیت "UP" همراه با یک آدرس IP برای LLMNR یا MulticastDNS مناسب است، و هر رابطی که UP باشد و آدرس IP داشته باشد برای DNS مناسب است. به رابطهٔ بین بیت‌های ارائه‌شده در اینجا با ویژگی‌های LLMNR و MulticastDNS که در رابط Link نیز ارائه شده‌اند توجه کنید؛ ویژگی‌های بعدی نشان می‌دهند چه چیزی برای استفاده در رابط *پیکربندی* شده است، در حالی که فیلد اول نشان می‌دهد با در نظر گرفتن توانایی‌های رابط، در عمل چه چیزی روی رابط استفاده می‌شود.

ویژگی DNSSECSupported یک فیلد بولی را ارائه می‌دهد که نشان می‌دهد آیا DNSSEC در حال حاضر روی رابط پیکربندی شده و مورد استفاده است یا خیر. توجه داشته باشید که اگر DNSSEC روی یک رابط فعال باشد، در دسترس فرض می‌شود تا زمانی که شناسایی شود سرور پیکربندی‌شده در واقع از آن پشتیبانی نمی‌کند. بنابراین، این ویژگی ممکن است در ابتدا گزارش دهد که DNSSEC روی رابط پشتیبانی می‌شود.

ویژگی DefaultRoute یک فیلد بولی را ارائه می‌دهد که نشان می‌دهد آیا از این رابط به عنوان مسیر پیش‌فرض برای پرس‌وجوهای نام استفاده خواهد شد یا خیر. به SetLinkDefaultRoute() در بالا مراجعه کنید.

سایر ویژگی‌ها وضعیت تنظیمات پیکربندی مختلف برای پیوند را منعکس می‌کنند که می‌توانند با فراخوانی متدهای مختلف مانند SetDNS() یا SetLLMNR() تنظیم شوند.

بسیاری از متدهای گذرگاه که systemd-resolved ارائه می‌دهد (به‌ویژه متدهای تحلیل‌گر مانند ResolveHostname() روی رابط Manager) ممکن است برخی از خطاهای زیر را بازگردانند:

org.freedesktop.resolve1.NoNameServers

هیچ سرور DNS مناسبی برای تحلیل یک درخواست پیدا نشد.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.InvalidReply

پاسخی از سرور DNS انتخاب‌شده دریافت شد که مفهوم نبود.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.NoSuchRR

نام درخواستی وجود دارد، اما هیچ رکورد منبعی از نوع درخواست‌شده برای آن وجود ندارد. (این همان حالت NODATA در DNS است).

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.CNameLoop

جستجو به دلیل شناسایی یک حلقهٔ CNAME یا DNAME با شکست مواجه شد.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.Aborted

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

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.NoSuchService

جستجوی سرویس موفقیت‌آمیز بود، اما رکورد SRV گزارش داد که این سرویس در دسترس نیست.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.DnssecFailed

پاسخ دریافتی از اعتبارسنجی DNSSEC عبور نکرد.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.NoTrustAnchor

هیچ زنجیرهٔ اعتمادی برای پاسخ به یک لنگر اعتماد DNSSEC پیکربندی‌شده برقرار نشد.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.ResourceRecordTypeUnsupported

نوع رکورد منبع درخواستی روی سرورهای DNS انتخاب‌شده پشتیبانی نمی‌شود. این خطا برای مثال زمانی ایجاد می‌شود که یک رکورد RRSIG از یک سرور DNS که از DNSSEC پشتیبانی نمی‌کند، درخواست شود.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.NoSuchLink

هیچ رابط شبکه‌ای با نمایهٔ رابط شبکهٔ مشخص‌شده وجود ندارد.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.LinkBusy

تغییر پیکربندی درخواستی انجام نشد زیرا systemd-networkd(8) قبلاً کنترل رابط را به دست گرفته و داده‌های پیکربندی را برای آن فراهم کرده است.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.NetworkDown

جستجوی درخواستی با شکست مواجه شد زیرا سیستم در حال حاضر به هیچ شبکهٔ مناسبی متصل نیست.

افزوده‌شده در نسخه 246.

org.freedesktop.resolve1.DnsError.NXDOMAIN، org.freedesktop.resolve1.DnsError.REFUSED، ...

جستجو با یک کد بازگشتی DNS که حاکی از شکست است، با خطا مواجه شد. نام‌های خطای استفاده‌شده به عنوان پسوند در اینجا توسط IANA در کدهای بازگشتی DNS (DNS RCODEs)[4] تعریف شده‌اند.

افزوده‌شده در نسخه 246.

مثال ۱. درون‌نگری org.freedesktop.resolve1.Manager روی گذرگاه

$ gdbus introspect --system \
  --dest org.freedesktop.resolve1 \
  --object-path /org/freedesktop/resolve1

مثال ۲. درون‌نگری org.freedesktop.resolve1.Link روی گذرگاه

$ gdbus introspect --system \
  --dest org.freedesktop.resolve1 \
  --object-path /org/freedesktop/resolve1/link/_11

این رابط‌های D-Bus از دستورالعمل‌های معمول نسخه‌بندی رابط[5] پیروی می‌کنند.

systemd(1), systemd-resolved.service(8), resolvectl(1)

1.
نوشتن مدیران پیکربندی شبکه (Writing Network Configuration Managers)
https://wiki.freedesktop.org/www/Software/systemd/writing-network-configuration-managers
2.
نوشتن کلاینت‌های تحلیل‌گر نام (Writing Resolver Clients)
https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients
3.
RFC 1035
https://www.ietf.org/rfc/rfc1035.txt
4.
کدهای بازگشتی DNS (DNS RCODEs)
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
5.
دستورالعمل‌های معمول نسخه‌بندی رابط
https://0pointer.de/blog/projects/versioning-dbus.html
systemd 257.13