summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-server.h
AgeCommit message (Collapse)Author
2016-02-10tree-wide: remove Emacs lines from all filesDaniel Mack
This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.
2016-01-29resolved: log server type when switching serversZbigniew Jędrzejewski-Szmek
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.
2016-01-25resolved: log recognizably about DNSSEC downgradesLennart Poettering
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.
2016-01-17resolved: downgrade server feature level more aggressively when we have ↵Lennart Poettering
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.
2016-01-11resolved: rework how and when we detect whether our chosen DNS server knows ↵Lennart Poettering
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.
2016-01-11resolved: cache formatted server string in DnsServer structureLennart Poettering
This makes it easier to log information about a specific DnsServer object.
2016-01-11resolved: rework server feature level logicLennart Poettering
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.
2015-12-27resolved: rename "features" variables to "feature_level"Lennart Poettering
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.
2015-12-27resolved: rework OPT RR generation logicLennart Poettering
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.
2015-12-26resolved: add an automatic downgrade to non-DNSSEC modeLennart Poettering
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)
2015-12-03resolved: introduce a dnssec_mode setting per scopeLennart Poettering
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.
2015-11-27resolved: announce support for large UDP packetsTom Gundersen
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.
2015-11-27resolved: set the DNSSEC OK (DO) flagTom Gundersen
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).
2015-11-27resolved: implement minimal EDNS0 supportTom Gundersen
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).
2015-11-27resolved: degrade the feature level on explicit failureTom Gundersen
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.
2015-11-27resolved: fallback to TCP if UDP failsTom Gundersen
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>
2015-11-25resolved: unify DnsServer handling code between Link and ManagerLennart Poettering
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.
2015-11-25resolved: make sure order of dns servers is stableLennart Poettering
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.
2015-11-25resolved: drop unused enum typeLennart Poettering
2015-11-25resolved: rework dns server lifecycle logicLennart Poettering
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.
2015-11-25resolved: move dns server picking code from resolved-manager.c to ↵Lennart Poettering
resolved-dns-server.c
2015-11-25resolved: unify code for parsing dns server informationLennart Poettering
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
2015-08-03resolved: transaction - exponentially increase retry timeoutsTom Gundersen
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.
2015-07-14resolved: pin the server used in a transactionTom Gundersen
We want to discover information about the server and use that in when crafting packets to be resent.
2015-07-14resolved: reference count the dns serversTom Gundersen
We want to reference the servers from their active transactions, so make sure they stay around as long as the transaction does.
2015-02-23remove unused includesThomas Hindoe Paaboel Andersen
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.
2014-09-15hashmap: introduce hash_ops to make struct Hashmap smallerMichal Schmidt
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.
2014-08-12resolved: unify logic how we flush out DNS servers we learntLennart Poettering
2014-08-12resolved: filter out duplicate DNS servers when writing resolv.confLennart Poettering
2014-08-01resolved: rename resolved.h to resolved-manager.hLennart Poettering
After all it pretty much exlcusively containers definitions about the "Manager" object, hence let's call this the most obvious way.
2014-08-01resolved: beef up DNS server configuration logicLennart Poettering
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.
2014-07-29resolved: we don't need the DNS server "source" concept anymore, remove itLennart Poettering
2014-07-29resolve: add llmnr responder side for UDP and TCPLennart Poettering
Name defending is still missing.
2014-07-23resolved: don't read DHCP leasesTom Gundersen
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.
2014-07-18change type for address family to "int"Lennart Poettering
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.
2014-07-18resolved: add more constLennart Poettering
2014-07-16resolved: add a DNS client stub resolverLennart Poettering
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)