tree-wide: remove Emacs lines from all files This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.

resolved: allow configuration of routing domains in Domains=

resolved,networkd: add a per-interface DNSSEC setting This adds a DNSSEC= setting to .network files, and makes resolved honour them.

resolved,networkd: unify ResolveSupport enum networkd previously knew an enum "ResolveSupport" for configuring per-interface LLMNR support, resolved had a similar enum just called "Support", with the same value and similar pasers. Unify this, call the enum ResolveSupport, and port both daemons to it.

resolved: introduce a dnssec_mode setting per scope The setting controls which kind of DNSSEC validation is done: none at all, trusting the AD bit, or client-side validation. For now, no validation is implemented, hence the setting doesn't do much yet, except of toggling the CD bit in the generated messages if full client-side validation is requested.

resolved: unify DnsServer handling code between Link and Manager This copies concepts we introduced for the DnsSearchDomain stuff, and reworks the operations on lists of dns servers to be reusable and generic for use both with the Link and the Manager object.

resolved: add a generic DnsSearchDomain concept With this change, we add a new object to resolved, "DnsSearchDomain=" which wraps a search domain. This is then used to introduce a global search domain list, in addition to the existing per-link search domain list which is reword to make use of this new object too. This is preparation for implement proper unicast DNS search domain support.

resolved: make sure order of dns servers is stable Previously, we'd keep adding new dns servers we discover to the end of our linked list of servers. When we encountered a pre-existing server, we'd just leave it where it was. In essence that meant that old servers ended up at the front, and new servers at the end, but not in an order that would reflect the configuration. With this change we ensure that every pre-existing server we want to add again we move to the back of the linked list, so that the order is stable and in sync with the requested configuration.

resolved: make sure FallbackDNS= overrides built-in servers, doesn't extend them Closes #342.

resolved: rework dns server lifecycle logic Previously, there was a chance of memory corruption, because when switching to the next DNS server we didn't care whether they linked list of DNS servers was still valid. Clean up lifecycle of the dns server logic: - When a DnsServer object is still in the linked list of DnsServers for a link or the manager, indicate so with a "linked" boolean field, and never follow the linked list if that boolean is not set. - When picking a DnsServer to use for a link ot manager, always explicitly take a reference. This also rearranges some logic, to make the tracking of dns servers by link and globally more alike.

resolved: unify code for parsing dns server information Let's use the same parser when parsing dns server information from /etc/resolv.conf and our native configuration file. Also, move all code that manages lists of dns servers to a single place. resolved-dns-server.c

defs: rework CONF_DIRS_NULSTR() macro The macro is generically useful for putting together search paths, hence let's make it truly generic, by dropping the implicit ".d" appending it does, and leave that to the caller. Also rename it from CONF_DIRS_NULSTR() to CONF_PATHS_NULSTR(), since it's not strictly about dirs that way, but any kind of file system path. Also, mark CONF_DIR_SPLIT_USR() as internal macro by renaming it to _CONF_PATHS_SPLIT_USR() so that the leading underscore indicates that it's internal.

doc: correct punctuation and improve typography in documentation

util-lib: move CONF_DIRS_NULSTR definition to def.h After all, this is not some compiler or C magic, but something very specific to how systemd works, hence let's move it into def.h, and out of macro.h

util-lib: split out allocation calls into alloc-util.[ch]

util-lib: split string parsing related calls from util.[ch] into parse-util.[ch]

resolved: port to extract_first_word

util-lib: split our string related calls from util.[ch] into its own file string-util.[ch] There are more than enough calls doing string manipulations to deserve its own files, hence do something about it. This patch also sorts the #include blocks of all files that needed to be updated, according to the sorting suggestions from CODING_STYLE. Since pretty much every file needs our string manipulation functions this effectively means that most files have sorted #include blocks now. Also touches a few unrelated include files.

tree-wide: clean up log_syntax() usage - Rely everywhere that we use abs() on the error code passed in anyway, thus don't need to explicitly negate what we pass in - Never attach synthetic error number information to log messages. Only log about errors we *receive* with the error number we got there, don't log any synthetic error, that don#t even propagate, but just eat up. - Be more careful with attaching exactly the error we get, instead of errno or unrelated errors randomly. - Fix one occasion where the error number and line number got swapped. - Make sure we never tape over OOM issues, or inability to resolve specifiers

resolve: remove unused variable

resolved: Support resolved.conf.d directories in the usual search paths

resolved: unify logic how we flush out DNS servers we learnt

resolved: read the system /etc/resolv.conf unless we wrote it ourselves This way we integrate nicely with foreign network management stacks, such as NM.

resolved: beef up DNS server configuration logic We now maintain two lists of DNS servers: system servers and fallback servers. system servers are used in combination with any per-link servers. fallback servers are only used if there are no system servers or per-link servers configured. The system server list is supposed to be populated from a foreign tool's /etc/resolv.conf (not implemented yet). Also adds a configuration switch for LLMNR, that allows configuring whether LLMNR shall be used simply for resolving or also for responding.