Support additional `systemd-resolved` options / `org.freedesktop.resolve1` DBUS endpoints

Addresses #60; covers/obviates #92 and #99.

Marked as a draft because it is based on #100 (and also because it is not finished :).

The idea is to support additional systemd-resolved options by exposing new dhcp-option types that trigger org.freedesktop.resolve1 DBUS calls.

New `dhcp-option` types:

`FLUSH-CACHES`

Takes no argument.

Replaces the use of resolvectl flush-caches, and allows the user to control whether caches are flushed (current behavior is to flush unconditionally).

`RESET-SERVER-FEATURES`

Takes no argument.

resolvectl --help:

Forget learnt DNS server feature levels

`RESET-STATISTICS`

Takes no argument.

resolvectl --help:

Reset resolver statistics

`DEFAULT-ROUTE`

Takes a boolean argument.

man systemd.network, section on DNSDefaultRoute:

If true, this link's configured DNS servers are used for resolving domain names that do not match any link's configured Domains= setting. If false, this link's configured DNS servers are never used for such domains, and are exclusively used for resolving names that match at least one of the domains configured on this link.

`DNS-OVER-TLS`

Takes a boolean argument, or "opportunistic".

man resolved.conf:

If true all connections to the server will be encrypted. Note that this mode requires a DNS server that supports DNS-over-TLS and has a valid certificate. If the hostname was specified in DNS= by using the format "address#server_name" it is used to validate its certificate and also to enable Server Name Indication (SNI) when opening a TLS connection. Otherwise the certificate is checked against the server's IP. If the DNS server does not support DNS-over-TLS all DNS requests will fail.

When set to "opportunistic" DNS request are attempted to send encrypted with DNS-over-TLS. If the DNS server does not support TLS, DNS-over-TLS is disabled. Note that this mode makes DNS-over-TLS vulnerable to "downgrade" attacks, where an attacker might be able to trigger a downgrade to non-encrypted mode by synthesizing a response that suggests DNS-over-TLS was not supported. If set to false, DNS lookups are send over UDP.

`LLMNR`

Takes a boolean argument, or "resolve".

man resolved.conf:

Takes a boolean or "resolve". When true, enables Link-Local Multicast Name Resolution[1] on the link. When set to "resolve", only resolution is enabled, but not host registration and announcement. Defaults to true.

`MULTICAST-DNS`

Takes a boolean argument, or "resolve".

When true, enables Multicast DNS support on the link. When set to "resolve", only resolution is enabled, but not host or service registration and announcement. Defaults to false.

`DNSSEC-NEGATIVE-TRUST-ANCHORS`

Takes a single domain. May be specified multiple times in order to add multiple domains as negative trust anchors.

man resolved.conf:

If specified and DNSSEC is enabled, look-ups done via the interface's DNS server will be subject to the list of negative trust anchors, and not require authentication for the specified domains, or anything below it. Use this to disable DNSSEC authentication for specific private domains, that cannot be proven valid using the Internet DNS hierarchy. Defaults to the empty list.

Needs Feedback

`dhcp-option` names

Perhaps update-systemd-resolved-specific options should be flagged as such with (say) a special prefix? For instance, instead of just LLMNR, what about SYSTEMD-RESOLVED-LLMNR or RESOLVE1-LLMNR, or similar?

Argument validation

This changeset includes some light validation of arguments supplied to the various dhcp-options. Maybe it would be better to just punt to org.freedesktop.resolve1 to raise errors when appropriate?

TODO

Figure out how to test DNSSEC negative trust anchors.
Document the available options.

jonathanio / update-systemd-resolved