{ "mode": "man", "parameter": "org.freedesktop.resolve1", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/org.freedesktop.resolve1/5/json", "generated": "2026-05-30T06:07:51Z", "sections": { "NAME": { "content": "org.freedesktop.resolve1 - The D-Bus interface of systemd-resolved\n", "subsections": [] }, "INTRODUCTION": { "content": "systemd-resolved.service(8) is a system service that provides hostname resolution and caching\nusing DNS, LLMNR, and mDNS. It also does DNSSEC validation. This page describes the resolve\nsemantics and the D-Bus interface.\n\nThis page contains an API reference only. If you are looking for a longer explanation how to\nuse this API, please consult Writing Network Configuration Managers[1] and Writing Resolver\nClients[2].\n", "subsections": [] }, "THE MANAGER OBJECT": { "content": "The service exposes the following interfaces on the Manager object on the bus:\n\nnode /org/freedesktop/resolve1 {\ninterface org.freedesktop.resolve1.Manager {\nmethods:\nResolveHostname(in i ifindex,\nin s name,\nin i family,\nin t flags,\nout a(iiay) addresses,\nout s canonical,\nout t flags);\nResolveAddress(in i ifindex,\nin i family,\nin ay address,\nin t flags,\nout a(is) names,\nout t flags);\nResolveRecord(in i ifindex,\nin s name,\nin q class,\nin q type,\nin t flags,\nout a(iqqay) records,\nout t flags);\nResolveService(in i ifindex,\nin s name,\nin s type,\nin s domain,\nin i family,\nin t flags,\nout a(qqqsa(iiay)s) srvdata,\nout aay txtdata,\nout s canonicalname,\nout s canonicaltype,\nout s canonicaldomain,\nout t flags);\nGetLink(in i ifindex,\nout o path);\nSetLinkDNS(in i ifindex,\nin a(iay) addresses);\nSetLinkDNSEx(in i ifindex,\nin a(iayqs) addresses);\nSetLinkDomains(in i ifindex,\nin a(sb) domains);\nSetLinkDefaultRoute(in i ifindex,\nin b enable);\nSetLinkLLMNR(in i ifindex,\nin s mode);\nSetLinkMulticastDNS(in i ifindex,\nin s mode);\nSetLinkDNSOverTLS(in i ifindex,\nin s mode);\nSetLinkDNSSEC(in i ifindex,\nin s mode);\nSetLinkDNSSECNegativeTrustAnchors(in i ifindex,\nin as names);\nRevertLink(in i ifindex);\nRegisterService(in s name,\nin s nametemplate,\nin s type,\nin q serviceport,\nin q servicepriority,\nin q serviceweight,\nin aa{say} txtdatas,\nout o servicepath);\nUnregisterService(in o servicepath);\nResetStatistics();\nFlushCaches();\nResetServerFeatures();\nproperties:\nreadonly s LLMNRHostname = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s LLMNR = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s MulticastDNS = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s DNSOverTLS = '...';\nreadonly a(iiay) DNS = [...];\nreadonly a(iiayqs) DNSEx = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"const\")\nreadonly a(iiay) FallbackDNS = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"const\")\nreadonly a(iiayqs) FallbackDNSEx = [...];\nreadonly (iiay) CurrentDNSServer = ...;\nreadonly (iiayqs) CurrentDNSServerEx = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly a(isb) Domains = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly (tt) TransactionStatistics = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly (ttt) CacheStatistics = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s DNSSEC = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly (tttt) DNSSECStatistics = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly b DNSSECSupported = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly as DNSSECNegativeTrustAnchors = ['...', ...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s DNSStubListener = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s ResolvConfMode = '...';\n};\ninterface org.freedesktop.DBus.Peer { ... };\ninterface org.freedesktop.DBus.Introspectable { ... };\ninterface org.freedesktop.DBus.Properties { ... };\n};\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n", "subsections": [ { "name": "Methods", "content": "ResolveHostname() takes a hostname and resolves it to one or more IP addresses. As parameters\nit takes the Linux network interface index to execute the query on, or 0 if it may be done on\nany suitable interface. The name parameter specifies the hostname to resolve. Note that if\nrequired, IDNA conversion is applied to this name unless it is resolved via LLMNR or\nMulticastDNS. The family parameter limits the results to a specific address family. It may be\nAFINET, AFINET6 or AFUNSPEC. If AFUNSPEC is specified (recommended), both kinds are\nretrieved, subject to local network configuration (i.e. if no local, routable IPv6 address is\nfound, no IPv6 address is retrieved; and similarly for IPv4). A 64-bit flags field may be\nused to alter the behaviour of the resolver operation (see below). The method returns an\narray of address records. Each address record consists of the interface index the address\nbelongs to, an address family as well as a byte array with the actual IP address data (which\neither has 4 or 16 elements, depending on the address family). The returned address family\nwill be one of AFINET or AFINET6. For IPv6, the returned address interface index should be\nused to initialize the .sin6scopeid field of a struct sockaddrin6 instance to permit\nsupport for resolution to link-local IP addresses. The address array is followed by the\ncanonical name of the host, which may or may not be identical to the resolved hostname.\nFinally, a 64-bit flags field is returned that is defined similarly to the flags field that\nwas passed in, but contains information about the resolved data (see below). If the hostname\npassed in is an IPv4 or IPv6 address formatted as string, it is parsed, and the result is\nreturned. In this case, no network communication is done.\n\nResolveAddress() executes the reverse operation: it takes an IP address and acquires one or\nmore hostnames for it. As parameters it takes the interface index to execute the query on, or\n0 if all suitable interfaces are OK. The family parameter indicates the address family of the\nIP address to resolve. It may be either AFINET or AFINET6. The address parameter takes the\nraw IP address data (as either a 4 or 16 byte array). The flags input parameter may be used\nto alter the resolver operation (see below). The method returns an array of name records,\neach consisting of an interface index and a hostname. The flags output field contains\nadditional information about the resolver operation (see below).\n\nResolveRecord() takes a DNS resource record (RR) type, class and name, and retrieves the full\nresource record set (RRset), including the RDATA, for it. As parameter it takes the Linux\nnetwork interface index to execute the query on, or 0 if it may be done on any suitable\ninterface. The name parameter specifies the RR domain name to look up (no IDNA conversion is\napplied), followed by the 16-bit class and type fields (which may be ANY). Finally, a flags\nfield may be passed in to alter behaviour of the look-up (see below). On completion, an array\nof RR items is returned. Each array entry consists of the network interface index the RR was\ndiscovered on, the type and class field of the RR found, and a byte array of the raw RR\ndiscovered. The raw RR data starts with the RR's domain name, in the original casing,\nfollowed by the RR type, class, TTL and RDATA, in the binary format documented in\nRFC 1035[3]. For RRs that support name compression in the payload (such as MX or PTR), the\ncompression is expanded in the returned data.\n\nNote that currently, the class field has to be specified as IN or ANY. Specifying a different\nclass will return an error indicating that look-ups of this kind are unsupported. Similarly,\nsome special types are not supported either (AXFR, OPT, ...). While systemd-resolved parses\nand validates resource records of many types, it is crucial that clients using this API\nunderstand that the RR data originates from the network and should be thoroughly validated\nbefore use.\n\nResolveService() may be used to resolve a DNS SRV service record, as well as the hostnames\nreferenced in it, and possibly an accompanying DNS-SD TXT record containing additional\nservice metadata. The primary benefit of using this method over ResolveRecord() specifying\nthe SRV type is that it will resolve the SRV and TXT RRs as well as the hostnames referenced\nin the SRV in a single operation. As parameters it takes a Linux network interface index, a\nservice name, a service type and a service domain. This method may be invoked in three\ndifferent modes:\n\n1. To resolve a DNS-SD service, specify the service name (e.g. \"Lennart's Files\"), the\nservice type (e.g. \"webdav.tcp\") and the domain to search in (e.g. \"local\") as the\nthree service parameters. The service name must be in UTF-8 format, and no IDNA\nconversion is applied to it in this mode (as mandated by the DNS-SD specifications).\nHowever, if necessary, IDNA conversion is applied to the domain parameter.\n\n2. To resolve a plain SRV record, set the service name parameter to the empty string and set\nthe service type and domain properly. (IDNA conversion is applied to the domain, if\nnecessary.)\n\n3. Alternatively, leave both the service name and type empty and specify the full domain\nname of the SRV record (i.e. prefixed with the service type) in the domain parameter. (No\nIDNA conversion is applied in this mode.)\n\nThe family parameter of the ResolveService() method encodes the desired family of the\naddresses to resolve (use AFINET, AFINET6, or AFUNSPEC). If this is enabled (Use the\nNOADDRESS flag to turn address resolution off, see below). The flags parameter takes a\ncouple of flags that may be used to alter the resolver operation.\n\nOn completion, ResolveService() returns an array of SRV record structures. Each items\nconsisting of the priority, weight and port fields as well as the hostname to contact, as\nencoded in the SRV record. Immediately following is an array of the addresses of this\nhostname, with each item consisting of the interface index, the address family and the\naddress data in a byte array. This address array is followed by the canonicalized hostname.\nAfter this array of SRV record structures an array of byte arrays follows that encodes the\nTXT RR strings, in case DNS-SD look-ups are enabled. The next parameters are the canonical\nservice name, type and domain. This may or may not be identical to the parameters passed in.\nFinally, a flags field is returned that contains information about the resolver operation\nperformed.\n\nThe ResetStatistics() method resets the various statistics counters that systemd-resolved\nmaintains to zero. (For details, see the statistics properties below.)\n\nThe GetLink() method takes a network interface index and returns the object path to the\norg.freedesktop.resolve1.Link object corresponding to it.\n\nThe SetLinkDNS() method sets the DNS servers to use on a specific interface. This method (and\nthe following ones) may be used by network management software to configure per-interface DNS\nsettings. It takes a network interface index as well as an array of DNS server IP address\nrecords. Each array item consists of an address family (either AFINET or AFINET6), followed\nby a 4-byte or 16-byte array with the raw address data. This method is a one-step shortcut\nfor retrieving the Link object for a network interface using GetLink() (see above) and then\ninvoking the SetDNS() method (see below) on it.\n\nSetLinkDNSEx() is similar to SetLinkDNS(), but allows an IP port (instead of the default 53)\nand DNS name to be specified for each DNS server. The server name is used for Server Name\nIndication (SNI), which is useful when DNS-over-TLS is used. C.f. DNS= in resolved.conf(5).\n\nSetLinkDefaultRoute() specifies whether the link shall be used as the default route for name\nqueries. See the description of name routing in systemd-resolved.service(8) for details.\n\nThe SetLinkDomains() method sets the search and routing domains to use on a specific network\ninterface for DNS look-ups. It takes a network interface index and an array of domains, each\nwith a boolean parameter indicating whether the specified domain shall be used as a search\ndomain (false), or just as a routing domain (true). Search domains are used for qualifying\nsingle-label names into FQDN when looking up hostnames, as well as for making routing\ndecisions on which interface to send queries ending in the domain to. Routing domains are\nonly used for routing decisions and not used for single-label name qualification. Pass the\nsearch domains in the order they should be used.\n\nThe SetLinkLLMNR() method enables or disables LLMNR support on a specific network interface.\nIt takes a network interface index as well as a string that may either be empty or one of\n\"yes\", \"no\" or \"resolve\". If empty, the systemd-wide default LLMNR setting is used. If \"yes\",\nLLMNR is used for resolution of single-label names and the local hostname is registered on\nall local LANs for LLMNR resolution by peers. If \"no\", LLMNR is turned off fully on this\ninterface. If \"resolve\", LLMNR is only enabled for resolving names, but the local hostname is\nnot registered for other peers to use.\n\nSimilarly, the SetLinkMulticastDNS() method enables or disables MulticastDNS support on a\nspecific interface. It takes the same parameters as SetLinkLLMNR() described above.\n\nThe SetLinkDNSSEC() method enables or disables DNSSEC validation on a specific network\ninterface. It takes a network interface index as well as a string that may either be empty or\none of \"yes\", \"no\", or \"allow-downgrade\". When empty, the system-wide default DNSSEC setting\nis used. If \"yes\", full DNSSEC validation is done for all look-ups. If the selected DNS\nserver does not support DNSSEC, look-ups will fail if this mode is used. If \"no\", DNSSEC\nvalidation is fully disabled. If \"allow-downgrade\", DNSSEC validation is enabled, but is\nturned off automatically if the selected server does not support it (thus opening up\nbehaviour to downgrade attacks). Note that DNSSEC only applies to traditional DNS, not to\nLLMNR or MulticastDNS.\n\nThe SetLinkDNSSECNegativeTrustAnchors() method may be used to configure DNSSEC Negative Trust\nAnchors (NTAs) for a specific network interface. It takes a network interface index and a\nlist of domains as arguments.\n\nThe SetLinkDNSOverTLS() method enables or disables DNS-over-TLS. C.f. DNSOverTLS= in\nsystemd-resolved.service(8) for details.\n\nNetwork management software integrating with systemd-resolved should call SetLinkDNS() or\nSetLinkDNSEx(), SetLinkDefaultRoute(), SetLinkDomains() and others after the interface\nappeared in the kernel (and thus after a network interface index has been assigned), but\nbefore the network interfaces is activated (IFFUP set) so that all settings take effect\nduring the full time the network interface is up. It is safe to alter settings while the\ninterface is up, however. Use RevertLink() (described below) to reset all per-interface\nsettings.\n\nThe RevertLink() method may be used to revert all per-link settings described above to the\ndefaults.\n" }, { "name": "The Flags Parameter", "content": "The four methods above accept and return a 64-bit flags value. In most cases passing 0 is\nsufficient and recommended. However, the following flags are defined to alter the\nlook-up:\n\n#define SDRESOLVEDDNS (UINT64C(1) << 0)\n#define SDRESOLVEDLLMNRIPV4 (UINT64C(1) << 1)\n#define SDRESOLVEDLLMNRIPV6 (UINT64C(1) << 2)\n#define SDRESOLVEDMDNSIPV4 (UINT64C(1) << 3)\n#define SDRESOLVEDMDNSIPV6 (UINT64C(1) << 4)\n#define SDRESOLVEDNOCNAME (UINT64C(1) << 5)\n#define SDRESOLVEDNOTXT (UINT64C(1) << 6)\n#define SDRESOLVEDNOADDRESS (UINT64C(1) << 7)\n#define SDRESOLVEDNOSEARCH (UINT64C(1) << 8)\n#define SDRESOLVEDAUTHENTICATED (UINT64C(1) << 9)\n#define SDRESOLVEDNOVALIDATE (UINT64C(1) << 10)\n#define SDRESOLVEDNOSYNTHESIZE (UINT64C(1) << 11)\n#define SDRESOLVEDNOCACHE (UINT64C(1) << 12)\n#define SDRESOLVEDNOZONE (UINT64C(1) << 13)\n#define SDRESOLVEDNOTRUSTANCHOR (UINT64C(1) << 14)\n#define SDRESOLVEDNONETWORK (UINT64C(1) << 15)\n#define SDRESOLVEDREQUIREPRIMARY (UINT64C(1) << 16)\n#define SDRESOLVEDCLAMPTTL (UINT64C(1) << 17)\n#define SDRESOLVEDCONFIDENTIAL (UINT64C(1) << 18)\n#define SDRESOLVEDSYNTHETIC (UINT64C(1) << 19)\n#define SDRESOLVEDFROMCACHE (UINT64C(1) << 20)\n#define SDRESOLVEDFROMZONE (UINT64C(1) << 21)\n#define SDRESOLVEDFROMTRUSTANCHOR (UINT64C(1) << 22)\n#define SDRESOLVEDFROMNETWORK (UINT64C(1) << 23)\n\n\nOn input, the first five flags control the protocols to use for the look-up. They refer\nto classic unicast DNS, LLMNR via IPv4/UDP and IPv6/UDP respectively, as well as\nMulticastDNS via IPv4/UDP and IPv6/UDP. If all of these five bits are off on input (which\nis strongly recommended) the look-up will be done via all suitable protocols for the\nspecific look-up. Note that these flags operate as filter only, but cannot force a\nlook-up to be done via a protocol. Specifically, systemd-resolved will only route\nlook-ups within the .local TLD to MulticastDNS (plus some reverse look-up address\ndomains), and single-label names to LLMNR (plus some reverse address lookup domains). It\nwill route neither of these to Unicast DNS servers. Also, it will do LLMNR and Multicast\nDNS only on interfaces suitable for multicast.\n\nOn output, these five flags indicate which protocol was used to execute the operation,\nand hence where the data was found.\n\nThe primary use cases for these five flags are follow-up look-ups based on DNS data\nretrieved earlier. In this case it is often a good idea to limit the follow-up look-up to\nthe protocol that was used to discover the first DNS result.\n\nThe NOCNAME flag controls whether CNAME/DNAME resource records shall be followed during\nthe look-up. This flag is only available at input, none of the functions will return it\non output. If a CNAME/DNAME RR is discovered while resolving a hostname, an error is\nreturned instead. By default, when the flag is off, CNAME/DNAME RRs are followed.\n\nThe NOTXT and NOADDRESS flags only influence operation of the ResolveService() method.\nThey are only defined for input, not output. If NOTXT is set, the DNS-SD TXT RR look-up\nis not done in the same operation. If NOADDRESS is set, the discovered hostnames are not\nimplicitly translated to their addresses.\n\nThe NOSEARCH flag turns off the search domain logic. It is only defined for input in\nResolveHostname(). When specified, single-label hostnames are not qualified using defined\nsearch domains, if any are configured. Note that ResolveRecord() will never qualify\nsingle-label domain names using search domains. Also note that multi-label hostnames are\nnever subject to search list expansion.\n\nThe AUTHENTICATED bit is defined only in the output flags of the four functions. If set,\nthe returned data has been fully authenticated. Specifically, this bit is set for all\nDNSSEC-protected data for which a full trust chain may be established to a trusted domain\nanchor. It is also set for locally synthesized data, such as \"localhost\" or data from\n/etc/hosts. Moreover, it is set for all LLMNR or mDNS RRs which originate from the local\nhost. Applications that require authenticated RR data for operation should check this\nflag before trusting the data. Note that systemd-resolved will never return invalidated\ndata, hence this flag simply allows to discern the cases where data is known to be\ntrusted, or where there is proof that the data is \"rightfully\" unauthenticated (which\nincludes cases where the underlying protocol or server does not support authenticating\ndata).\n\nNOVALIDATE can be set to disable validation via DNSSEC even if it would normally be\nused.\n\nThe next four flags allow disabling certain sources during resolution. NOSYNTHESIZE\ndisables synthetic records, e.g. the local host name, see section SYNTHETIC RECORDS in\nsystemd-resolved.service(8) for more information. NOCACHE disables the use of the cache\nof previously resolved records. NOZONE disables answers using locally registered public\nLLMNR/mDNS resource records. NOTRUSTANCHOR disables answers using locally configured\ntrust anchors. NONETWORK requires all answers to be provided without using the network,\ni.e. either from local sources or the cache.\n\nWith REQUIREPRIMARY the request must be answered from a \"primary\" answer, i.e. not from\nresource records acquired as a side-effect of a previous transaction.\n\nWith CLAMPTTL, if reply is answered from cache, the TTLs will be adjusted by age of\ncache entry.\n\nThe next six bits flags are used in output and provide information about the source of\nthe answer. CONFIDENTIAL means the query was resolved via encrypted channels or never\nleft this system. FROMSYNTHETIC means the query was (at least partially) synthesized.\nFROMCACHE means the query was answered (at least partially) using the cache. FROMZONE\nmeans the query was answered (at least partially) using LLMNR/mDNS. FROMTRUSTANCHOR\nmeans the query was answered (at least partially) using local trust anchors. FROMNETWORK\nmeans the query was answered (at least partially) using the network.\n" }, { "name": "Properties", "content": "The LLMNR and MulticastDNS properties report whether LLMNR and MulticastDNS are (globally)\nenabled. Each may be one of \"yes\", \"no\", and \"resolve\". See SetLinkLLMNR() and\nSetLinkMulticastDNS() above.\n\nLLMNRHostname contains the hostname currently exposed on the network via LLMNR. It usually\nfollows the system hostname as may be queried via gethostname(3), but may differ if a\nconflict is detected on the network.\n\nDNS and DNSEx contain arrays of all DNS servers currently used by systemd-resolved. DNS\ncontains information similar to the DNS server data in /run/systemd/resolve/resolv.conf. Each\nstructure in the array consists of a numeric network interface index, an address family, and\na byte array containing the DNS server address (either 4 bytes in length for IPv4 or 16 bytes\nin lengths for IPv6). DNSEx is similar, but additionally contains the IP port and server\nname (used for Server Name Indication, SNI). Both arrays contain DNS servers configured\nsystem-wide, including those possibly read from a foreign /etc/resolv.conf or the DNS=\nsetting in /etc/systemd/resolved.conf, as well as per-interface DNS server information either\nretrieved from systemd-networkd(8), or configured by external software via SetLinkDNS() or\nSetLinkDNSEx() (see above). The network interface index will be 0 for the system-wide\nconfigured services and non-zero for the per-link servers.\n\nFallbackDNS and FallbackDNSEx contain arrays of all DNS servers configured as fallback\nservers, if any, using the same format as DNS and DNSEx described above. See the description\nof FallbackDNS= in resolved.conf(5) for the description of when those servers are used.\n\nCurrentDNSServer and CurrentDNSServerEx specify the server that is currently used for query\nresolution, in the same format as a single entry in the DNS and DNSEx arrays described above.\n\nSimilarly, the Domains property contains an array of all search and routing domains currently\nused by systemd-resolved. Each entry consists of a network interface index (again, 0 encodes\nsystem-wide entries), the actual domain name, and whether the entry is used only for routing\n(true) or for both routing and searching (false).\n\nThe TransactionStatistics property contains information about the number of transactions\nsystemd-resolved has processed. It contains a pair of unsigned 64-bit counters, the first\ncontaining the number of currently ongoing transactions, the second the number of total\ntransactions systemd-resolved is processing or has processed. The latter value may be reset\nusing the ResetStatistics() method described above. Note that the number of transactions does\nnot directly map to the number of issued resolver bus method calls. While simple look-ups\nusually require a single transaction only, more complex look-ups might result in more, for\nexample when CNAMEs or DNSSEC are in use.\n\nThe CacheStatistics property contains information about the executed cache operations so far.\nIt exposes three 64-bit counters: the first being the total number of current cache entries\n(both positive and negative), the second the number of cache hits, and the third the number\nof cache misses. The latter counters may be reset using ResetStatistics() (see above).\n\nThe DNSSEC property specifies current status of DNSSEC validation. It is one of \"yes\"\n(validation is enforced), \"no\" (no validation is done), \"allow-downgrade\" (validation is done\nif the current DNS server supports it). See the description of DNSSEC= in resolved.conf(5).\n\nThe DNSSECStatistics property contains information about the DNSSEC validations executed so\nfar. It contains four 64-bit counters: the number of secure, insecure, bogus, and\nindeterminate DNSSEC validations so far. The counters are increased for each validated RRset,\nand each non-existance proof. The secure counter is increased for each operation that\nsuccessfully verified a signed reply, the insecure counter is increased for each operation\nthat successfully verified that an unsigned reply is rightfully unsigned. The bogus counter\nis increased for each operation where the validation did not check out and the data is likely\nto have been tempered with. Finally the indeterminate counter is increased for each operation\nwhich did not complete because the necessary keys could not be acquired or the cryptographic\nalgorithms were unknown.\n\nThe DNSSECSupported boolean property reports whether DNSSEC is enabled and the selected DNS\nservers support it. It combines information about system-wide and per-link DNS settings (see\nbelow), and only reports true if DNSSEC is enabled and supported on every interface for which\nDNS is configured and for the system-wide settings if there are any. Note that\nsystemd-resolved assumes DNSSEC is supported by DNS servers until it verifies that this is\nnot the case. Thus, the reported value may initially be true, until the first transactions\nare executed.\n\nThe DNSOverTLS boolean property reports whether DNS-over-TLS is enabled.\n\nThe ResolvConfMode property exposes how /etc/resolv.conf is managed on the host. Currently,\nthe values \"uplink\", \"stub\", \"static\" (these three correspond to the three different files\nsystemd-resolved.service provides), \"foreign\" (the file is managed by admin or another\nservice, systemd-resolved.service just consumes it), \"missing\" (/etc/resolv.conf is missing).\n\nThe DNSStubListener property reports whether the stub listener on port 53 is enabled.\nPossible values are \"yes\" (enabled), \"no\" (disabled), \"udp\" (only the UDP listener is\nenabled), and \"tcp\" (only the TCP listener is enabled).\n" } ] }, "LINK OBJECT": { "content": "node /org/freedesktop/resolve1/link/1 {\ninterface org.freedesktop.resolve1.Link {\nmethods:\nSetDNS(in a(iay) addresses);\nSetDNSEx(in a(iayqs) addresses);\nSetDomains(in a(sb) domains);\nSetDefaultRoute(in b enable);\nSetLLMNR(in s mode);\nSetMulticastDNS(in s mode);\nSetDNSOverTLS(in s mode);\nSetDNSSEC(in s mode);\nSetDNSSECNegativeTrustAnchors(in as names);\nRevert();\nproperties:\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly t ScopesMask = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly a(iay) DNS = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly a(iayqs) DNSEx = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly (iay) CurrentDNSServer = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly (iayqs) CurrentDNSServerEx = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly a(sb) Domains = [...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly b DefaultRoute = ...;\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s LLMNR = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s MulticastDNS = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s DNSOverTLS = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly s DNSSEC = '...';\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly as DNSSECNegativeTrustAnchors = ['...', ...];\n@org.freedesktop.DBus.Property.EmitsChangedSignal(\"false\")\nreadonly b DNSSECSupported = ...;\n};\ninterface org.freedesktop.DBus.Peer { ... };\ninterface org.freedesktop.DBus.Introspectable { ... };\ninterface org.freedesktop.DBus.Properties { ... };\n};\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nFor each Linux network interface a \"Link\" object is created which exposes per-link DNS\nconfiguration and state. Use GetLink() on the Manager interface to retrieve the object path\nfor a link object given the network interface index (see above).\n", "subsections": [ { "name": "Methods", "content": "The various methods exposed by the Link interface are equivalent to their similarly named\ncounterparts on the Manager interface. e.g. SetDNS() on the Link object maps to SetLinkDNS()\non the Manager object, the main difference being that the later expects an interface index to\nbe specified. Invoking the methods on the Manager interface has the benefit of reducing\nroundtrips, as it is not necessary to first request the Link object path via GetLink() before\ninvoking the methods. The same relationship holds for SetDNSEx(), SetDomains(),\nSetDefaultRoute(), SetLLMNR(), SetMulticastDNS(), SetDNSOverTLS(), SetDNSSEC(),\nSetDNSSECNegativeTrustAnchors(), and Revert(). For further details on these methods see the\nManager documentation above.\n" }, { "name": "Properties", "content": "ScopesMask defines which resolver scopes are currently active on this interface. This 64-bit\nunsigned integer field is a bit mask consisting of a subset of the bits of the flags\nparameter describe above. Specifically, it may have the DNS, LLMNR and MDNS bits (the latter\nin IPv4 and IPv6 flavours) set. Each individual bit is set when the protocol applies to a\nspecific interface and is enabled for it. It is unset otherwise. Specifically, a\nmulticast-capable interface in the \"UP\" state with an IP address is suitable for LLMNR or\nMulticastDNS, and any interface that is UP and has an IP address is suitable for DNS. Note\nthe relationship of the bits exposed here with the LLMNR and MulticastDNS properties also\nexposed on the Link interface. The latter expose what is *configured* to be used on the\ninterface, the former expose what is actually used on the interface, taking into account the\nabilities of the interface.\n\nDNSSECSupported exposes a boolean field that indicates whether DNSSEC is currently configured\nand in use on the interface. Note that if DNSSEC is enabled on an interface, it is assumed\navailable until it is detected that the configured server does not actually support it. Thus,\nthis property may initially report that DNSSEC is supported on an interface.\n\nDefaultRoute exposes a boolean field that indicates whether the interface will be used as\ndefault route for name queries. See SetLinkDefaultRoute() above.\n\nThe other properties reflect the state of the various configuration settings for the link\nwhich may be set with the various methods calls such as SetDNS() or SetLLMNR().\n" } ] }, "COMMON ERRORS": { "content": "Many bus methods systemd-resolved exposes (in particular the resolver methods such as\nResolveHostname() on the Manager interface) may return some of the following errors:\n", "subsections": [ { "name": "org.freedesktop.resolve1.NoNameServers", "content": "No suitable DNS servers were found to resolve a request.\n" }, { "name": "org.freedesktop.resolve1.InvalidReply", "content": "A response from the selected DNS server was not understood.\n" }, { "name": "org.freedesktop.resolve1.NoSuchRR", "content": "The requested name exists, but there is no resource record of the requested type for it.\n(This is the DNS NODATA case).\n" }, { "name": "org.freedesktop.resolve1.CNameLoop", "content": "The look-up failed because a CNAME or DNAME loop was detected.\n" }, { "name": "org.freedesktop.resolve1.Aborted", "content": "The look-up was aborted because the selected protocol became unavailable while the\noperation was ongoing.\n" }, { "name": "org.freedesktop.resolve1.NoSuchService", "content": "A service look-up was successful, but the SRV record reported that the service is not\navailable.\n" }, { "name": "org.freedesktop.resolve1.DnssecFailed", "content": "The acquired response did not pass DNSSEC validation.\n" }, { "name": "org.freedesktop.resolve1.NoTrustAnchor", "content": "No chain of trust could be established for the response to a configured DNSSEC trust\nanchor.\n" }, { "name": "org.freedesktop.resolve1.ResourceRecordTypeUnsupported", "content": "The requested resource record type is not supported on the selected DNS servers. This\nerror is generated for example when an RRSIG record is requested from a DNS server that\ndoes not support DNSSEC.\n" }, { "name": "org.freedesktop.resolve1.NoSuchLink", "content": "No network interface with the specified network interface index exists.\n" }, { "name": "org.freedesktop.resolve1.LinkBusy", "content": "The requested configuration change could not be made because systemd-networkd(8), already\ntook possession of the interface and supplied configuration data for it.\n" }, { "name": "org.freedesktop.resolve1.NetworkDown", "content": "The requested look-up failed because the system is currently not connected to any\nsuitable network.\n\norg.freedesktop.resolve1.DnsError.NXDOMAIN, org.freedesktop.resolve1.DnsError.REFUSED, ...\nThe look-up failed with a DNS return code reporting a failure. The error names used as\nsuffixes here are defined in by IANA in DNS RCODEs[4].\n" } ] }, "EXAMPLES": { "content": "", "subsections": [ { "name": "Example 1. Introspect org.freedesktop.resolve1.Manager on the bus", "content": "$ gdbus introspect --system \\\n--dest org.freedesktop.resolve1 \\\n--object-path /org/freedesktop/resolve1\n\n" }, { "name": "Example 2. Introspect org.freedesktop.resolve1.Link on the bus", "content": "$ gdbus introspect --system \\\n--dest org.freedesktop.resolve1 \\\n--object-path /org/freedesktop/resolve1/link/11\n\n" } ] }, "VERSIONING": { "content": "These D-Bus interfaces follow the usual interface versioning guidelines[5].\n", "subsections": [] }, "NOTES": { "content": "1. Writing Network Configuration Managers\nhttps://wiki.freedesktop.org/www/Software/systemd/writing-network-configuration-managers\n\n2. Writing Resolver Clients\nhttps://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients\n\n3. RFC 1035\nhttps://www.ietf.org/rfc/rfc1035.txt\n\n4. DNS RCODEs\nhttps://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6\n\n5. the usual interface versioning guidelines\nhttp://0pointer.de/blog/projects/versioning-dbus.html\n\n\n\nsystemd 249 ORG.FREEDESKTOP.RESOLVE1(5)", "subsections": [] } }, "summary": "org.freedesktop.resolve1 - The D-Bus interface of systemd-resolved", "flags": [], "examples": [ "$ gdbus introspect --system \\", "--dest org.freedesktop.resolve1 \\", "--object-path /org/freedesktop/resolve1", "$ gdbus introspect --system \\", "--dest org.freedesktop.resolve1 \\", "--object-path /org/freedesktop/resolve1/link/11" ], "see_also": [] }