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: log server type when switching servers I'm not defining _DNS_SERVER_TYPE_MAX/INVALID as usual in the enum, because it wouldn't be used, and then gcc would complain that various enums don't test for _DNS_SERVER_TYPE_MAX. It seems better to define the macro rather than add assert_not_reached() in multiple places.

resolved: log recognizably about DNSSEC downgrades If we downgrade from DNSSEC to non-DNSSEC mode, let's log about this in a recognizable way (i.e. with a message ID), after all, this is of major importance.

resolved: downgrade server feature level more aggressively when we have reason to This adds logic to downgrade the feature level more aggressively when we have reason to. Specifically: - When we get a response packet that lacks an OPT RR for a query that had it. If so, downgrade immediately to UDP mode, i.e. don't generate EDNS0 packets anymore. - When we get a response which we are sure should be signed, but lacks RRSIG RRs, we downgrade to EDNS0 mode, i.e. below DO mode, since DO is apparently not really supported. This should increase compatibility with servers that generate non-sensical responses if they messages with OPT RRs and suchlike, for example the situation described here: https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-November/000376.html This also changes the downgrade code to explain in a debug log message why a specific downgrade happened.

resolved: rework how and when we detect whether our chosen DNS server knows DNSSEC Move detection into a set of new functions, that check whether one specific server can do DNSSEC, whether a server and a specific transaction can do DNSSEC, or whether a transaction and all its auxiliary transactions could do so. Also, do these checks both before we acquire additional RRs for the validation (so that we can skip them if the server doesn't do DNSSEC anyway), and after we acquired them all (to see if any of the lookups changed our opinion about the servers). THis also tightens the checks a bit: a server that lacks TCP support is considered incompatible with DNSSEC too.

resolved: cache formatted server string in DnsServer structure This makes it easier to log information about a specific DnsServer object.

resolved: rework server feature level logic This changes the DnsServer logic to count failed UDP and TCP failures separately. This is useful so that we don't end up downgrading the feature level from one UDP level to a lower UDP level just because a TCP connection we did because of a TC response failed. This also adds accounting of truncated packets. If we detect incoming truncated packets, and count too many failed TCP connections (which is the normal fall back if we get a trucnated UDP packet) we downgrade the feature level, given that the responses at the current levels don't get through, and we somehow need to make sure they become smaller, which they will do if we don't request DNSSEC or EDNS support. This makes resolved work much better with crappy DNS servers that do not implement TCP and only limited UDP packet sizes, but otherwise support DNSSEC RRs. They end up choking on the generally larger DNSSEC RRs and there's no way to retrieve the full data.

resolved: rename "features" variables to "feature_level" The name "features" suggests an orthogonal bitmap or suchlike, but the variables really encode only a linear set of feature levels. The type used is already called DnsServerFeatureLevel, hence fix up the variables accordingly, too.

resolved: rework OPT RR generation logic This moves management of the OPT RR out of the scope management and into the server and packet management. There are now explicit calls for appending and truncating the OPT RR from a packet (dns_packet_append_opt() and dns_packet_truncate_opt()) as well as a call to do the right thing depending on a DnsServer's feature level (dns_server_adjust_opt()). This also unifies the code to pick a server between the TCP and UDP code paths, and makes sure the feature level used for the transaction is selected at the time the server is picked, and not changed until the next time we pick a server. The server selction code is now unified in dns_transaction_pick_server(). This all fixes problems when changing between UDP and TCP communication for the same server, and makes sure the UDP and TCP codepaths are more alike. It also makes sure we never keep the UDP port open when switchung to TCP, so that we don't have to handle incoming datagrams on the latter we don't expect. As the new code picks the DNS server at the time we make a connection, we don't need to invalidate the DNS server anymore when changing to the next one, thus dns_transaction_next_dns_server() has been removed.

resolved: add an automatic downgrade to non-DNSSEC mode This adds a mode that makes resolved automatically downgrade from DNSSEC support to classic non-DNSSEC resolving if the configured DNS server is not capable of DNSSEC. Enabling this mode increases compatibility with crappy network equipment, but of course opens up the system to downgrading attacks. The new mode can be enabled by setting DNSSEC=downgrade-ok in resolved.conf. DNSSEC=yes otoh remains a "strict" mode, where DNS resolving rather fails then allow downgrading. Downgrading is done: - when the server does not support EDNS0+DO - or when the server supports it but does not augment returned RRs with RRSIGs. The latter is detected when requesting DS or SOA RRs for the root domain (which is necessary to do proofs for unsigned data)

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: announce support for large UDP packets This is often needed for proper DNSSEC support, and even to handle AAAA records without falling back to TCP. If the path between the client and server is fully compliant, this should always work, however, that is not the case, and overlarge packets will get mysteriously lost in some cases. For that reason, we use a similar fallback mechanism as we do for palin EDNS0, EDNS0+DO, etc.: The large UDP size feature is different from the other supported feature, as we cannot simply verify that it works based on receiving a reply (as the server will usually send us much smaller packets than what we claim to support, so simply receiving a reply does not mean much). For that reason, we keep track of the largest UDP packet we ever received, as this is the smallest known good size (defaulting to the standard 512 bytes). If announcing the default large size of 4096 fails (in the same way as the other features), we fall back to the known good size. The same logic of retrying after a grace-period applies.

resolved: set the DNSSEC OK (DO) flag This indicates that we can handle DNSSEC records (per RFC3225), even if all we do is silently drop them. This feature requires EDNS0 support. As we do not yet support larger UDP packets, this feature increases the risk of getting truncated packets. Similarly to how we fall back to plain UDP if EDNS0 fails, we will fall back to plain EDNS0 if EDNS0+DO fails (with the same logic of remembering success and retrying after a grace period after failure).

resolved: implement minimal EDNS0 support This is a minimal implementation of RFC6891. Only default values are used, so in reality this will be a noop. EDNS0 support is dependent on the current server's feature level, so appending the OPT pseudo RR is done when the packet is emitted, rather than when it is assembled. To handle different feature levels on retransmission, we strip off the OPT RR again after sending the packet. Similarly, to how we fall back to TCP if UDP fails, we fall back to plain UDP if EDNS0 fails (but if EDNS0 ever succeeded we never fall back again, and after a timeout we will retry EDNS0).

resolved: degrade the feature level on explicit failure Previously, we would only degrade on packet loss, but when adding EDNS0 support, we also have to handle the case where the server replies with an explicit error.

resolved: fallback to TCP if UDP fails This is inspired by the logic in BIND [0], follow-up patches will implement the reset of that scheme. If we get a server error back, or if after several attempts we don't get a reply at all, we switch from UDP to TCP for the given server for the current and all subsequent requests. However, if we ever successfully received a reply over UDP, we never fall back to TCP, and once a grace-period has passed, we try to upgrade again to using UDP. The grace-period starts off at five minutes after the current feature level was verified and then grows exponentially to six hours. This is to mitigate problems due to temporary lack of network connectivity, but at the same time avoid flooding the network with retries when the feature attempted feature level genuinely does not work. Note that UDP is likely much more commonly supported than TCP, but depending on the path between the client and the server, we may have more luck with TCP in case something is wrong. We really do prefer UDP though, as that is much more lightweight, that is why TCP is only the last resort. [0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>

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: 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: drop unused enum type

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: move dns server picking code from resolved-manager.c to resolved-dns-server.c

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

resolved: transaction - exponentially increase retry timeouts Rather than fixing this to 5s for unicast DNS and 1s for LLMNR, start at a tenth of those values and increase exponentially until the old values are reached. For LLMNR the recommended timeout for IEEE802 networks (which basically means all of the ones we care about) is 100ms, so that should be uncontroversial. For unicast DNS I have found no recommended value. However, it seems vastly more likely that hitting a 500ms timeout is casued by a packet loss, rather than the RTT genuinely being greater than 500ms, so taking this as a startnig value seems reasonable to me. In the common case this greatly reduces the latency due to normal packet loss. Moreover, once we get support for probing for features, this means that we can send more packets before degrading the feature level whilst still allowing us to settle on the correct feature level in a reasonable timeframe. The timeouts are tracked per server (or per scope for the multicast protocols), and once a server (or scope) receives a successfull package the timeout is reset. We also track the largest RTT for the given server/scope, and always start our timouts at twice the largest observed RTT.

resolved: pin the server used in a transaction We want to discover information about the server and use that in when crafting packets to be resent.

resolved: reference count the dns servers We want to reference the servers from their active transactions, so make sure they stay around as long as the transaction does.

remove unused includes This patch removes includes that are not used. The removals were found with include-what-you-use which checks if any of the symbols from a header is in use.

hashmap: introduce hash_ops to make struct Hashmap smaller It is redundant to store 'hash' and 'compare' function pointers in struct Hashmap separately. The functions always comprise a pair. Store a single pointer to struct hash_ops instead. systemd keeps hundreds of hashmaps, so this saves a little bit of memory.

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

resolved: filter out duplicate DNS servers when writing resolv.conf

resolved: rename resolved.h to resolved-manager.h After all it pretty much exlcusively containers definitions about the "Manager" object, hence let's call this the most obvious way.

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.

resolved: we don't need the DNS server "source" concept anymore, remove it

resolve: add llmnr responder side for UDP and TCP Name defending is still missing.

resolved: don't read DHCP leases networkd will expose both statically configured DNS servers and servers receieved over DHCP in sd_network_get_dns(), so no need to keep the distinction in resolved.

change type for address family to "int" Let's settle on a single type for all address family values, even if UNIX is very inconsitent on the precise type otherwise. Given that socket() is the primary entrypoint for the sockets API, and that uses "int", and "int" is relatively simple and generic, we settle on "int" for this.

resolved: add more const

resolved: add a DNS client stub resolver Let's turn resolved into a something truly useful: a fully asynchronous DNS stub resolver that subscribes to network changes. (More to come: caching, LLMNR, mDNS/DNS-SD, DNSSEC, IDN, NSS module)