summaryrefslogtreecommitdiff
path: root/src/resolve
AgeCommit message (Collapse)Author
2016-01-18resolved: minor optimization for dns_question_is_equal()Lennart Poettering
If the poinetrs are equal, we don't have to do a deep comparison. This is similar to a similar optimization we already have in place for RRs and keys.
2016-01-18resolved: be slightly stricter when validating DnsQuestionLennart Poettering
Also verify whether the DNS RR types are actually suitable for a question.
2016-01-18resolved: make key argument of dns_question_contains() constLennart Poettering
2016-01-17resolved: fix logging about DNAME redirectionLennart Poettering
2016-01-17resolved: when we find a DNAME RR, don't insist in a signed CNAME RRLennart Poettering
If we have a signed DNAME RR response, there's no need to insist on a signature for a CNAME RR response, after all it is unlikely to be signed, given the implicit synthethis of CNAME through DNAME RRs.
2016-01-17resolved: update DNSSEC TODOLennart Poettering
2016-01-17resolved: try to reduce number or DnsResourceKeys we keep around by merging themLennart Poettering
Quite often we read the same RR key multiple times from the same message. Try to replace them by a single object when we notice this. Do so again when we add things to the cache. This should reduce memory consumption a tiny bit.
2016-01-17resolved: when switching between DNSSEC modes, possibly flush cachesLennart Poettering
If the networkd configuration changes during runtime, make sure to flush all caches when we switch from a less trusted to a more trusted mode.
2016-01-17resolved: when the server feature level changes between query and response ↵Lennart Poettering
restart transaction In some cases we learn something about a server's feature level through its responses. If we notice that after doing basic checking of a response, and after collecting all auxiliary DNSSEC info the feature level of the server is lower than where we started, restart the whole transaction. This is useful to deal with servers that response rubbish when talked to with too high feature levels.
2016-01-17resolved: check OPT RR before accepting a reply for verification of server ↵Lennart Poettering
feature level Let's make sure we first check if the OPT was lost in the reply, before we accept a reply as successful and use it for verifying the current feature level.
2016-01-17resolved: when restarting a DNS transaction, remove all auxiliary DNSSEC ↵Lennart Poettering
transactions When we restart a DNS transaction, remove all connections to any auxiliary DNSSEC transactions, after all we might acquire completely different data this time, requiring different auxiliary DNSSEC transactions.
2016-01-17resolved: when we receive an reply which is OPT-less or RRSIG-less, ↵Lennart Poettering
downgrade what we verified If we receive a reply that lacks the OPT RR, then this is reason to downgrade what was verified before, as it's apparently no longer true, and the previous OPT RR we saw was only superficially OK. Similar, if we realize that RRSIGs are not augmented, then also downgrade the feature level that was verified, as DNSSEC is after all not supported. This check is in particular necessary, as we might notice the fact that RRSIG is not augmented only very late, when verifying the root domain. Also, when verifying a successful response, actually take in consideration that it might have been reported already that RRSIG or OPT are missing in the response.
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-17resolved: ignore invalid OPT RRs in incoming packetsLennart Poettering
This validates OPT RRs more rigorously, before honouring them: if we any of the following condition holds, we'll ignore them: a) Multiple OPT RRs in the same message b) OPT RR not owned by the root domain c) OPT RR in the wrong section (Belkin routers do this) d) OPT RR contain rfc6975 algorithm data (Belkin routers do this) e) OPT version is not 0 f) OPT payload doesn't add up with the lengths Note that d) may be an indication that the server just blindly copied OPT data from the response into the reply. RFC6975 data is only supposed to be included in queries, and we do so. It's not supposed to be included in responses (and the RFC is very clear on that). Hence if we get it back in a reply, then the server probably just copied the OPT RR.
2016-01-17resolved: update RFCs list and TODO listLennart Poettering
2016-01-17resolved: add complex test caseLennart Poettering
This new test case tries to resolve a couple of known domains, to verify the validation results. It talks to resolved via the bus, thus comprehensively testing the whole shebang. Of course, it requires network connectivity and a DNSSEC capable DNS server, hence this is a manual test.
2016-01-17resolved: complete NSEC non-existance proofsLennart Poettering
This fills in the last few gaps: - When checking if a domain is non-existing, also check that no wildcard for it exists - Ensure we don't base "covering" tests on NSEC RRs from a parent zone - Refuse to accept expanded wildcard NSEC RRs for absence proofs.
2016-01-17resolved: make sure the NSEC proof-of-non-existance check also looks for ↵Lennart Poettering
wildcard domains
2016-01-17resolved: on negative NODATA replies, properly deal with empty non-terminalsLennart Poettering
empty non-terminals generally lack NSEC RRs, which means we can deduce their existance only from the fact that there are other RRs that contain them in their suffix. Specifically, the NSEC proof for NODATA on ENTs works by sending the NSEC whose next name is a suffix of the queried name to the client. Use this information properly.
2016-01-17resolved: rename dnssec_verify_dnskey() → dnssec_verify_dnskey_by_ds()Lennart Poettering
This should clarify that this is not regular signature-based validation, but validation through DS RR fingerprints.
2016-01-17resolved: be stricter when using NSEC3Lennart Poettering
We can user signer and synthesizing source information to check that the NSEC3 RRs we want to use are actually reasonable and properly signed.
2016-01-17resolved: when validating an RRset, store information about the synthesizing ↵Lennart Poettering
source and zone in each RR Having this information available is useful when we need to check whether various RRs are suitable for proofs. This information is stored in the RRs as number of labels to skip from the beginning of the owner name to reach the synthesizing source/signer. Simple accessor calls are then added to retrieve the signer/source from the RR using this information. This also moves validation of a a number of RRSIG parameters into a new call dnssec_rrsig_prepare() that as side-effect initializes the two numeric values.
2016-01-17resolved: do not use NSEC RRs from the wrong zone for proofsLennart Poettering
When proving NODATA DS lookups we need to insist on looking at the parent zone's NSEC RR, not the child zone's. When proving any other NODATA lookups we need to insist on looking at the child zone's NSEC RR, not the parent's.
2016-01-17resolved: ignore DS RRs without generating an error if they use an ↵Lennart Poettering
unsupported digest algorithm
2016-01-17resolved: some RR types may appear only or not at all in a zone apexLennart Poettering
Add extra checks when validating with RRSIGs. This follows recommendations from: http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/NotesOnDNSSSEC.htm
2016-01-13resolved: implement the full NSEC and NSEC3 postive wildcard proofsLennart Poettering
2016-01-13resolved: refuse validating wildcard RRs for SOA, NSEC3, DNAMELennart Poettering
2016-01-13resolved: properly handles RRs in domains beginning in an asterisk labelLennart Poettering
Properly handle RRs that begin with an asterisk label. These are the unexpanded forms of wildcard domains and appear in NSEC RRs for example. We need to make sure we handle the signatures of these RRs properly, since they mostly are considered normal RRs, except that the RRSIG labels counter is one off for them, as the asterisk label is always excluded of the signature.
2016-01-13resolved: optimize dnssec_verify_rrset() a bitLennart Poettering
Let's determine the source of synthesis once instead of for each RR in the RRset.
2016-01-13resolved: allocate bounded strings on stack instead of heap, if we canLennart Poettering
2016-01-13resolved: consider inverted RRSIG validity intervals expiredLennart Poettering
2016-01-11resolved: improve query RR type error wording a bitLennart Poettering
2016-01-11resolved: don#t allow explicit queries for RRSIG RRsLennart Poettering
We wouldn't know how to validate them, since they are the signatures, and hence have no signatures.
2016-01-11resolved: refuse doing queries for known-obsolete RR typesLennart Poettering
Given how fragile DNS servers are with some DNS types, and given that we really should avoid confusing them with known-weird lookups, refuse doing lookups for known-obsolete RR types.
2016-01-11resolved: rename DnsTransaction's current_features field to ↵Lennart Poettering
current_feature_level This is a follow-up for f4461e5641d53f27d6e76e0607bdaa9c0c58c1f6.
2016-01-11resolved: split out resetting of DNS server counters into a function call of ↵Lennart Poettering
its own A suggested by Vito Caputo: https://github.com/systemd/systemd/pull/2289#discussion-diff-49276220
2016-01-11resolved: accept rightfully unsigned NSEC responsesLennart Poettering
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.
2016-01-11resolved: add missing case to switch statementLennart Poettering
2016-01-11resolved: log why we use TCP when UDP isn't supported by a serverLennart Poettering
2016-01-11resolved: log about truncated replies before trying again, not afterLennart Poettering
2016-01-11resolved: don't attempt to send queries for DNSSEC RR types to servers not ↵Lennart Poettering
supporting them If we already degraded the feature level below DO don't bother with sending requests for DS, DNSKEY, RRSIG, NSEC, NSEC3 or NSEC3PARAM RRs. After all, we cannot do DNSSEC validation then anyway, and we better not press a legacy server like this with such modern concepts. This also has the benefit that when we try to validate a response we received using DNSSEC, and we detect a limited server support level while doing so, all further auxiliary DNSSEC queries will fail right-away.
2016-01-11resolved: log about reasons for switching to TCPLennart Poettering
2016-01-11resolved: when we get a packet failure from a server, don't downgrade UDP to ↵Lennart Poettering
TCP or vice versa Under the assumption that packet failures (i.e. FORMERR, SERVFAIL, NOTIMP) are caused by packet contents, not used transport, we shouldn't switch between UDP and TCP when we get them, but only downgrade the higher levels down to UDP.
2016-01-11resolved: properly handle UDP ICMP errors as lost packetsLennart Poettering
UDP ICMP errors are reported to us via recvmsg() when we read a reply. Handle this properly, and consider this a lost packet, and retry the connection. This also adds some additional logging for invalid incoming packets.
2016-01-11resolved: when we get a TCP connection failure, try againLennart Poettering
Previously, when we couldn't connect to a DNS server via TCP we'd abort the whole transaction using a "connection-failure" state. This change removes that, and counts failed connections as "lost packet" events, so that we switch back to the UDP protocol again.
2016-01-11resolved: when DNS/TCP doesn't work, try DNS/UDP againLennart Poettering
If we failed to contact a DNS server via TCP, bump of the feature level to UDP again. This way we'll switch back between UDP and TCP if we fail to contact a host. Generally, we prefer UDP over TCP, which is why UDP is a higher feature level. But some servers only support UDP but not TCP hence when reaching the lowest feature level of TCP and want to downgrade from there, pick UDP again. We this keep downgrading until we reach TCP and then we cycle through UDP and TCP.
2016-01-11resolved: introduce dns_transaction_retry() and use it everywhereLennart Poettering
The code to retry transactions has been used over and over again, simplify it by replacing it by a new function.
generated by cgit v1.2.3-54-g00ecf (git 2.45.2) at 2024-07-25 13:39:46 +0000