{
    "mode": "info",
    "parameter": "org.freedesktop.resolve1",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/org.freedesktop.resolve1/json",
    "generated": "2026-07-05T11:54:06Z",
    "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\nresolution and caching using DNS, LLMNR, and mDNS. It also does DNSSEC\nvalidation. This page describes the resolve semantics and the D-Bus\ninterface.\n\nThis page contains an API reference only. If you are looking for a\nlonger explanation how to use this API, please consult Writing Network\nConfiguration Managers[1] and Writing Resolver Clients[2].\n",
            "subsections": []
        },
        "THE MANAGER OBJECT": {
            "content": "The service exposes the following interfaces on the Manager object on\nthe 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\nMethods\nResolveHostname() takes a hostname and resolves it to one or more IP\naddresses. As parameters it takes the Linux network interface index to\nexecute the query on, or 0 if it may be done on any suitable interface.\nThe name parameter specifies the hostname to resolve. Note that if\nrequired, IDNA conversion is applied to this name unless it is resolved\nvia LLMNR or MulticastDNS. The family parameter limits the results to a\nspecific address family. It may be AFINET, AFINET6 or AFUNSPEC. If\nAFUNSPEC is specified (recommended), both kinds are retrieved, subject\nto local network configuration (i.e. if no local, routable IPv6 address\nis found, no IPv6 address is retrieved; and similarly for IPv4). A\n64-bit flags field may be used to alter the behaviour of the resolver\noperation (see below). The method returns an array of address records.\nEach address record consists of the interface index the address belongs\nto, an address family as well as a byte array with the actual IP\naddress data (which either has 4 or 16 elements, depending on the\naddress family). The returned address family will be one of AFINET or\nAFINET6. For IPv6, the returned address interface index should be used\nto initialize the .sin6scopeid field of a struct sockaddrin6\ninstance to permit support for resolution to link-local IP addresses.\nThe address array is followed by the canonical name of the host, which\nmay or may not be identical to the resolved hostname. Finally, a 64-bit\nflags field is returned that is defined similarly to the flags field\nthat was passed in, but contains information about the resolved data\n(see below). If the hostname passed in is an IPv4 or IPv6 address\nformatted as string, it is parsed, and the result is returned. In this\ncase, no network communication is done.\n\nResolveAddress() executes the reverse operation: it takes an IP address\nand acquires one or more hostnames for it. As parameters it takes the\ninterface index to execute the query on, or 0 if all suitable\ninterfaces are OK. The family parameter indicates the address family of\nthe IP address to resolve. It may be either AFINET or AFINET6. The\naddress parameter takes the raw IP address data (as either a 4 or 16\nbyte array). The flags input parameter may be used to alter the\nresolver operation (see below). The method returns an array of name\nrecords, each consisting of an interface index and a hostname. The\nflags output field contains additional information about the resolver\noperation (see below).\n\nResolveRecord() takes a DNS resource record (RR) type, class and name,\nand retrieves the full resource record set (RRset), including the\nRDATA, for it. As parameter it takes the Linux network interface index\nto 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\n(no IDNA conversion is applied), followed by the 16-bit class and type\nfields (which may be ANY). Finally, a flags field may be passed in to\nalter behaviour of the look-up (see below). On completion, an array of\nRR items is returned. Each array entry consists of the network\ninterface index the RR was discovered on, the type and class field of\nthe RR found, and a byte array of the raw RR discovered. The raw RR\ndata starts with the RR's domain name, in the original casing, followed\nby the RR type, class, TTL and RDATA, in the binary format documented\nin RFC 1035[3]. For RRs that support name compression in the payload\n(such as MX or PTR), the compression is expanded in the returned data.\n\nNote that currently, the class field has to be specified as IN or ANY.\nSpecifying a different class will return an error indicating that\nlook-ups of this kind are unsupported. Similarly, some special types\nare not supported either (AXFR, OPT, ...). While systemd-resolved\nparses and validates resource records of many types, it is crucial that\nclients using this API understand that the RR data originates from the\nnetwork and should be thoroughly validated before use.\n\nResolveService() may be used to resolve a DNS SRV service record, as\nwell as the hostnames referenced in it, and possibly an accompanying\nDNS-SD TXT record containing additional service metadata. The primary\nbenefit of using this method over ResolveRecord() specifying the SRV\ntype is that it will resolve the SRV and TXT RRs as well as the\nhostnames referenced in the SRV in a single operation. As parameters it\ntakes a Linux network interface index, a service name, a service type\nand a service domain. This method may be invoked in three different\nmodes:\n\n1. To resolve a DNS-SD service, specify the service name (e.g.\n\"Lennart's Files\"), the service type (e.g.  \"webdav.tcp\") and the\ndomain to search in (e.g.  \"local\") as the three service\nparameters. 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\nspecifications). However, if necessary, IDNA conversion is applied\nto the domain parameter.\n\n2. To resolve a plain SRV record, set the service name parameter to\nthe empty string and set the service type and domain properly.\n(IDNA conversion is applied to the domain, if necessary.)\n\n3. Alternatively, leave both the service name and type empty and\nspecify the full domain name of the SRV record (i.e. prefixed with\nthe service type) in the domain parameter. (No IDNA conversion is\napplied in this mode.)\n\nThe family parameter of the ResolveService() method encodes the desired\nfamily of the addresses to resolve (use AFINET, AFINET6, or\nAFUNSPEC). If this is enabled (Use the NOADDRESS flag to turn address\nresolution off, see below). The flags parameter takes a couple of flags\nthat may be used to alter the resolver operation.\n\nOn completion, ResolveService() returns an array of SRV record\nstructures. Each items consisting of the priority, weight and port\nfields as well as the hostname to contact, as encoded in the SRV\nrecord. Immediately following is an array of the addresses of this\nhostname, with each item consisting of the interface index, the address\nfamily and the address data in a byte array. This address array is\nfollowed by the canonicalized hostname. After this array of SRV record\nstructures an array of byte arrays follows that encodes the TXT RR\nstrings, in case DNS-SD look-ups are enabled. The next parameters are\nthe canonical service name, type and domain. This may or may not be\nidentical to the parameters passed in. Finally, a flags field is\nreturned that contains information about the resolver operation\nperformed.\n\nThe ResetStatistics() method resets the various statistics counters\nthat systemd-resolved maintains to zero. (For details, see the\nstatistics properties below.)\n\nThe GetLink() method takes a network interface index and returns the\nobject path to the org.freedesktop.resolve1.Link object corresponding\nto it.\n\nThe SetLinkDNS() method sets the DNS servers to use on a specific\ninterface. This method (and the following ones) may be used by network\nmanagement software to configure per-interface DNS settings. It takes a\nnetwork interface index as well as an array of DNS server IP address\nrecords. Each array item consists of an address family (either AFINET\nor AFINET6), followed by a 4-byte or 16-byte array with the raw\naddress data. This method is a one-step shortcut for retrieving the\nLink object for a network interface using GetLink() (see above) and\nthen invoking the SetDNS() method (see below) on it.\n\nSetLinkDNSEx() is similar to SetLinkDNS(), but allows an IP port\n(instead of the default 53) and DNS name to be specified for each DNS\nserver. The server name is used for Server Name Indication (SNI), which\nis 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\ndefault route for name queries. See the description of name routing in\nsystemd-resolved.service(8) for details.\n\nThe SetLinkDomains() method sets the search and routing domains to use\non a specific network interface for DNS look-ups. It takes a network\ninterface index and an array of domains, each with a boolean parameter\nindicating whether the specified domain shall be used as a search\ndomain (false), or just as a routing domain (true). Search domains are\nused for qualifying single-label names into FQDN when looking up\nhostnames, as well as for making routing decisions on which interface\nto send queries ending in the domain to. Routing domains are only used\nfor routing decisions and not used for single-label name qualification.\nPass the search domains in the order they should be used.\n\nThe SetLinkLLMNR() method enables or disables LLMNR support on a\nspecific network interface. It takes a network interface index as well\nas a string that may either be empty or one of \"yes\", \"no\" or\n\"resolve\". If empty, the systemd-wide default LLMNR setting is used. If\n\"yes\", LLMNR is used for resolution of single-label names and the local\nhostname is registered on all local LANs for LLMNR resolution by peers.\nIf \"no\", LLMNR is turned off fully on this interface. If \"resolve\",\nLLMNR 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\nMulticastDNS support on a specific interface. It takes the same\nparameters as SetLinkLLMNR() described above.\n\nThe SetLinkDNSSEC() method enables or disables DNSSEC validation on a\nspecific network interface. It takes a network interface index as well\nas a string that may either be empty or one of \"yes\", \"no\", or\n\"allow-downgrade\". When empty, the system-wide default DNSSEC setting\nis used. If \"yes\", full DNSSEC validation is done for all look-ups. If\nthe selected DNS server does not support DNSSEC, look-ups will fail if\nthis mode is used. If \"no\", DNSSEC validation is fully disabled. If\n\"allow-downgrade\", DNSSEC validation is enabled, but is turned off\nautomatically if the selected server does not support it (thus opening\nup behaviour to downgrade attacks). Note that DNSSEC only applies to\ntraditional DNS, not to LLMNR or MulticastDNS.\n\nThe SetLinkDNSSECNegativeTrustAnchors() method may be used to configure\nDNSSEC Negative Trust Anchors (NTAs) for a specific network interface.\nIt takes a network interface index and a list of domains as arguments.\n\nThe SetLinkDNSOverTLS() method enables or disables DNS-over-TLS. C.f.\nDNSOverTLS= in systemd-resolved.service(8) for details.\n\nNetwork management software integrating with systemd-resolved should\ncall SetLinkDNS() or SetLinkDNSEx(), SetLinkDefaultRoute(),\nSetLinkDomains() and others after the interface appeared in the kernel\n(and thus after a network interface index has been assigned), but\nbefore the network interfaces is activated (IFFUP set) so that all\nsettings take effect during the full time the network interface is up.\nIt is safe to alter settings while the interface is up, however. Use\nRevertLink() (described below) to reset all per-interface settings.\n\nThe RevertLink() method may be used to revert all per-link settings\ndescribed above to the defaults.\n\nThe Flags Parameter\nThe four methods above accept and return a 64-bit flags value. In\nmost cases passing 0 is sufficient and recommended. However, the\nfollowing flags are defined to alter the look-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\nOn input, the first five flags control the protocols to use for the\nlook-up. They refer to classic unicast DNS, LLMNR via IPv4/UDP and\nIPv6/UDP respectively, as well as MulticastDNS via IPv4/UDP and\nIPv6/UDP. If all of these five bits are off on input (which is\nstrongly recommended) the look-up will be done via all suitable\nprotocols for the specific look-up. Note that these flags operate\nas filter only, but cannot force a look-up to be done via a\nprotocol. Specifically, systemd-resolved will only route look-ups\nwithin the .local TLD to MulticastDNS (plus some reverse look-up\naddress domains), and single-label names to LLMNR (plus some\nreverse address lookup domains). It will route neither of these to\nUnicast DNS servers. Also, it will do LLMNR and Multicast DNS only\non interfaces suitable for multicast.\n\nOn output, these five flags indicate which protocol was used to\nexecute the operation, and hence where the data was found.\n\nThe primary use cases for these five flags are follow-up look-ups\nbased on DNS data retrieved earlier. In this case it is often a\ngood idea to limit the follow-up look-up to the protocol that was\nused to discover the first DNS result.\n\nThe NOCNAME flag controls whether CNAME/DNAME resource records\nshall be followed during the look-up. This flag is only available\nat input, none of the functions will return it on output. If a\nCNAME/DNAME RR is discovered while resolving a hostname, an error\nis returned instead. By default, when the flag is off, CNAME/DNAME\nRRs are followed.\n\nThe NOTXT and NOADDRESS flags only influence operation of the\nResolveService() method. They are only defined for input, not\noutput. If NOTXT is set, the DNS-SD TXT RR look-up is not done in\nthe same operation. If NOADDRESS is set, the discovered hostnames\nare not implicitly translated to their addresses.\n\nThe NOSEARCH flag turns off the search domain logic. It is only\ndefined for input in ResolveHostname(). When specified,\nsingle-label hostnames are not qualified using defined search\ndomains, if any are configured. Note that ResolveRecord() will\nnever qualify single-label domain names using search domains. Also\nnote that multi-label hostnames are never subject to search list\nexpansion.\n\nThe AUTHENTICATED bit is defined only in the output flags of the\nfour functions. If set, the returned data has been fully\nauthenticated. Specifically, this bit is set for all\nDNSSEC-protected data for which a full trust chain may be\nestablished to a trusted domain anchor. It is also set for locally\nsynthesized data, such as \"localhost\" or data from /etc/hosts.\nMoreover, it is set for all LLMNR or mDNS RRs which originate from\nthe local host. Applications that require authenticated RR data for\noperation should check this flag before trusting the data. Note\nthat systemd-resolved will never return invalidated data, hence\nthis flag simply allows to discern the cases where data is known to\nbe trusted, or where there is proof that the data is \"rightfully\"\nunauthenticated (which includes cases where the underlying protocol\nor server does not support authenticating data).\n\nNOVALIDATE can be set to disable validation via DNSSEC even if it\nwould normally be used.\n\nThe next four flags allow disabling certain sources during\nresolution. NOSYNTHESIZE disables synthetic records, e.g. the\nlocal host name, see section SYNTHETIC RECORDS in systemd-\nresolved.service(8) for more information. NOCACHE disables the use\nof the cache of previously resolved records. NOZONE disables\nanswers using locally registered public LLMNR/mDNS resource\nrecords. NOTRUSTANCHOR disables answers using locally configured\ntrust anchors. NONETWORK requires all answers to be provided\nwithout using the network, i.e. either from local sources or the\ncache.\n\nWith REQUIREPRIMARY the request must be answered from a \"primary\"\nanswer, i.e. not from resource records acquired as a side-effect of\na previous transaction.\n\nWith CLAMPTTL, if reply is answered from cache, the TTLs will be\nadjusted by age of cache entry.\n\nThe next six bits flags are used in output and provide information\nabout the source of the answer. CONFIDENTIAL means the query was\nresolved via encrypted channels or never left this system.\nFROMSYNTHETIC means the query was (at least partially)\nsynthesized. FROMCACHE means the query was answered (at least\npartially) using the cache. FROMZONE means the query was answered\n(at least partially) using LLMNR/mDNS. FROMTRUSTANCHOR means the\nquery was answered (at least partially) using local trust anchors.\nFROMNETWORK means the query was answered (at least partially)\nusing the network.\n\nProperties\nThe LLMNR and MulticastDNS properties report whether LLMNR and\nMulticastDNS are (globally) enabled. Each may be one of \"yes\", \"no\",\nand \"resolve\". See SetLinkLLMNR() and SetLinkMulticastDNS() above.\n\nLLMNRHostname contains the hostname currently exposed on the network\nvia LLMNR. It usually follows the system hostname as may be queried via\ngethostname(3), but may differ if a conflict is detected on the\nnetwork.\n\nDNS and DNSEx contain arrays of all DNS servers currently used by\nsystemd-resolved.  DNS contains information similar to the DNS server\ndata in /run/systemd/resolve/resolv.conf. Each structure in the array\nconsists of a numeric network interface index, an address family, and a\nbyte array containing the DNS server address (either 4 bytes in length\nfor IPv4 or 16 bytes in lengths for IPv6).  DNSEx is similar, but\nadditionally contains the IP port and server name (used for Server Name\nIndication, SNI). Both arrays contain DNS servers configured\nsystem-wide, including those possibly read from a foreign\n/etc/resolv.conf or the DNS= setting in /etc/systemd/resolved.conf, as\nwell as per-interface DNS server information either retrieved from\nsystemd-networkd(8), or configured by external software via\nSetLinkDNS() or SetLinkDNSEx() (see above). The network interface index\nwill be 0 for the system-wide configured services and non-zero for the\nper-link servers.\n\nFallbackDNS and FallbackDNSEx contain arrays of all DNS servers\nconfigured as fallback servers, if any, using the same format as DNS\nand DNSEx described above. See the description of FallbackDNS= in\nresolved.conf(5) for the description of when those servers are used.\n\nCurrentDNSServer and CurrentDNSServerEx specify the server that is\ncurrently used for query resolution, in the same format as a single\nentry in the DNS and DNSEx arrays described above.\n\nSimilarly, the Domains property contains an array of all search and\nrouting domains currently used by systemd-resolved. Each entry consists\nof a network interface index (again, 0 encodes system-wide entries),\nthe 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\nnumber of transactions systemd-resolved has processed. It contains a\npair of unsigned 64-bit counters, the first containing the number of\ncurrently ongoing transactions, the second the number of total\ntransactions systemd-resolved is processing or has processed. The\nlatter value may be reset using the ResetStatistics() method described\nabove. Note that the number of transactions does not directly map to\nthe number of issued resolver bus method calls. While simple look-ups\nusually require a single transaction only, more complex look-ups might\nresult in more, for example when CNAMEs or DNSSEC are in use.\n\nThe CacheStatistics property contains information about the executed\ncache operations so far. It exposes three 64-bit counters: the first\nbeing the total number of current cache entries (both positive and\nnegative), the second the number of cache hits, and the third the\nnumber of cache misses. The latter counters may be reset using\nResetStatistics() (see above).\n\nThe DNSSEC property specifies current status of DNSSEC validation. It\nis one of \"yes\" (validation is enforced), \"no\" (no validation is done),\n\"allow-downgrade\" (validation is done if the current DNS server\nsupports it). See the description of DNSSEC= in resolved.conf(5).\n\nThe DNSSECStatistics property contains information about the DNSSEC\nvalidations executed so far. It contains four 64-bit counters: the\nnumber of secure, insecure, bogus, and indeterminate DNSSEC validations\nso far. The counters are increased for each validated RRset, and each\nnon-existance proof. The secure counter is increased for each operation\nthat successfully verified a signed reply, the insecure counter is\nincreased for each operation that successfully verified that an\nunsigned reply is rightfully unsigned. The bogus counter is increased\nfor each operation where the validation did not check out and the data\nis likely to have been tempered with. Finally the indeterminate counter\nis increased for each operation which did not complete because the\nnecessary keys could not be acquired or the cryptographic algorithms\nwere unknown.\n\nThe DNSSECSupported boolean property reports whether DNSSEC is enabled\nand the selected DNS servers support it. It combines information about\nsystem-wide and per-link DNS settings (see below), and only reports\ntrue if DNSSEC is enabled and supported on every interface for which\nDNS is configured and for the system-wide settings if there are any.\nNote that systemd-resolved assumes DNSSEC is supported by DNS servers\nuntil it verifies that this is not the case. Thus, the reported value\nmay initially be true, until the first transactions are executed.\n\nThe DNSOverTLS boolean property reports whether DNS-over-TLS is\nenabled.\n\nThe ResolvConfMode property exposes how /etc/resolv.conf is managed on\nthe host. Currently, the values \"uplink\", \"stub\", \"static\" (these three\ncorrespond to the three different files systemd-resolved.service\nprovides), \"foreign\" (the file is managed by admin or another service,\nsystemd-resolved.service just consumes it), \"missing\" (/etc/resolv.conf\nis missing).\n\nThe DNSStubListener property reports whether the stub listener on port\n53 is enabled. Possible values are \"yes\" (enabled), \"no\" (disabled),\n\"udp\" (only the UDP listener is enabled), and \"tcp\" (only the TCP\nlistener is enabled).\n",
            "subsections": []
        },
        "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\nFor each Linux network interface a \"Link\" object is created which\nexposes per-link DNS configuration and state. Use GetLink() on the\nManager interface to retrieve the object path for a link object given\nthe network interface index (see above).\n\nMethods\nThe various methods exposed by the Link interface are equivalent to\ntheir similarly named counterparts on the Manager interface. e.g.\nSetDNS() on the Link object maps to SetLinkDNS() on the Manager object,\nthe main difference being that the later expects an interface index to\nbe specified. Invoking the methods on the Manager interface has the\nbenefit of reducing roundtrips, as it is not necessary to first request\nthe Link object path via GetLink() before invoking the methods. The\nsame relationship holds for SetDNSEx(), SetDomains(),\nSetDefaultRoute(), SetLLMNR(), SetMulticastDNS(), SetDNSOverTLS(),\nSetDNSSEC(), SetDNSSECNegativeTrustAnchors(), and Revert(). For further\ndetails on these methods see the Manager documentation above.\n\nProperties\nScopesMask defines which resolver scopes are currently active on this\ninterface. This 64-bit unsigned integer field is a bit mask consisting\nof a subset of the bits of the flags parameter describe above.\nSpecifically, it may have the DNS, LLMNR and MDNS bits (the latter in\nIPv4 and IPv6 flavours) set. Each individual bit is set when the\nprotocol applies to a specific interface and is enabled for it. It is\nunset otherwise. Specifically, a multicast-capable interface in the\n\"UP\" state with an IP address is suitable for LLMNR or MulticastDNS,\nand any interface that is UP and has an IP address is suitable for DNS.\nNote the relationship of the bits exposed here with the LLMNR and\nMulticastDNS properties also exposed on the Link interface. The latter\nexpose what is *configured* to be used on the interface, the former\nexpose 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\nis currently configured and in use on the interface. Note that if\nDNSSEC is enabled on an interface, it is assumed available until it is\ndetected that the configured server does not actually support it. Thus,\nthis property may initially report that DNSSEC is supported on an\ninterface.\n\nDefaultRoute exposes a boolean field that indicates whether the\ninterface will be used as default route for name queries. See\nSetLinkDefaultRoute() above.\n\nThe other properties reflect the state of the various configuration\nsettings for the link which may be set with the various methods calls\nsuch as SetDNS() or SetLLMNR().\n",
            "subsections": []
        },
        "COMMON ERRORS": {
            "content": "Many bus methods systemd-resolved exposes (in particular the resolver\nmethods such as ResolveHostname() on the Manager interface) may return\nsome of the following errors:\n\norg.freedesktop.resolve1.NoNameServers\nNo suitable DNS servers were found to resolve a request.\n\norg.freedesktop.resolve1.InvalidReply\nA response from the selected DNS server was not understood.\n\norg.freedesktop.resolve1.NoSuchRR\nThe requested name exists, but there is no resource record of the\nrequested type for it. (This is the DNS NODATA case).\n\norg.freedesktop.resolve1.CNameLoop\nThe look-up failed because a CNAME or DNAME loop was detected.\n\norg.freedesktop.resolve1.Aborted\nThe look-up was aborted because the selected protocol became\nunavailable while the operation was ongoing.\n\norg.freedesktop.resolve1.NoSuchService\nA service look-up was successful, but the SRV record reported that\nthe service is not available.\n\norg.freedesktop.resolve1.DnssecFailed\nThe acquired response did not pass DNSSEC validation.\n\norg.freedesktop.resolve1.NoTrustAnchor\nNo chain of trust could be established for the response to a\nconfigured DNSSEC trust anchor.\n\norg.freedesktop.resolve1.ResourceRecordTypeUnsupported\nThe requested resource record type is not supported on the selected\nDNS servers. This error is generated for example when an RRSIG\nrecord is requested from a DNS server that does not support DNSSEC.\n\norg.freedesktop.resolve1.NoSuchLink\nNo network interface with the specified network interface index\nexists.\n\norg.freedesktop.resolve1.LinkBusy\nThe requested configuration change could not be made because\nsystemd-networkd(8), already took possession of the interface and\nsupplied configuration data for it.\n\norg.freedesktop.resolve1.NetworkDown\nThe requested look-up failed because the system is currently not\nconnected to any suitable network.\n\norg.freedesktop.resolve1.DnsError.NXDOMAIN,\norg.freedesktop.resolve1.DnsError.REFUSED, ...\nThe look-up failed with a DNS return code reporting a failure. The\nerror names used as suffixes here are defined in by IANA in\nDNS RCODEs[4].\n",
            "subsections": []
        },
        "EXAMPLES": {
            "content": "Example 1. Introspect org.freedesktop.resolve1.Manager on the bus\n\n$ gdbus introspect --system \\\n--dest org.freedesktop.resolve1 \\\n--object-path /org/freedesktop/resolve1\n\nExample 2. Introspect org.freedesktop.resolve1.Link on the bus\n\n$ gdbus introspect --system \\\n--dest org.freedesktop.resolve1 \\\n--object-path /org/freedesktop/resolve1/link/11\n",
            "subsections": []
        },
        "VERSIONING": {
            "content": "These D-Bus interfaces follow the usual interface versioning\nguidelines[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\nsystemd 249                                        ORG.FREEDESKTOP.RESOLVE1(5)",
            "subsections": []
        }
    },
    "summary": "org.freedesktop.resolve1 - The D-Bus interface of systemd-resolved",
    "flags": [],
    "examples": [
        "Example 1. Introspect org.freedesktop.resolve1.Manager on the bus",
        "$ gdbus introspect --system \\",
        "--dest org.freedesktop.resolve1 \\",
        "--object-path /org/freedesktop/resolve1",
        "Example 2. Introspect org.freedesktop.resolve1.Link on the bus",
        "$ gdbus introspect --system \\",
        "--dest org.freedesktop.resolve1 \\",
        "--object-path /org/freedesktop/resolve1/link/11"
    ],
    "see_also": []
}