summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-dnssec.c
AgeCommit message (Collapse)Author
2016-04-13tree-wide: remove useless NULLs from strjoinaZbigniew Jędrzejewski-Szmek
The coccinelle patch didn't work in some places, I have no idea why.
2016-02-16Replace DNS_RESOURCE_KEY_NAME with a version which always returns "." for rootZbigniew Jędrzejewski-Szmek
This fixes formatting of root domain in debug messages: Old: systemd-resolved[10049]: Requesting DS to validate transaction 19313 (., DNSKEY with key tag: 19036). New: systemd-resolved[10049]: Requesting DS to validate transaction 19313 (, DNSKEY with key tag: 19036).
2016-02-13Merge pull request #2589 from keszybz/resolve-tool-2Lennart Poettering
Better support of OPENPGPKEY, CAA, TLSA packets and tests
2016-02-12Typo fixesMichael Biebl
2016-02-11Move initialize_libgcrypt to separate fileZbigniew Jędrzejewski-Szmek
It's annoying to have the exact same function in three places. It's stored in src/shared, but it's not added to the library to avoid the dependency on libgcrypt.
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-02-07treewide: fix typos and spacingTorstein Husebø
2016-01-31resolved: allow building without libgcryptMichael Olbrich
2016-01-31resolved: make dnssec_nsec_test_enclosed() staticMichael Olbrich
It's not used anywhere else.
2016-01-31resolved: reorder functionsMichael Olbrich
Preparation to make gcrypt optional.
2016-01-26update TODOLennart Poettering
This gets rid of the private DNSSEC TODO and moves it in the main TODO dump site, as the DNSSEC implementation is pretty complete now, and the remaining bits are low-priority.
2016-01-25resolved: don't insist in RRSIG metadata for NSEC3 RRs that have not been ↵Lennart Poettering
authenticated In some cases we get NSEC3 RRs that have not been authenticated (because the chain of trust to the root is somewhere broken). We can use these for checking negative replies, as long as we don't claim they were ultimately authenticated. This means we need to be able to deal with NSEC3 RRs that lack RRSIG metadata.
2016-01-25update DNSSEC TODOLennart Poettering
2016-01-25resolved: log each time we increase the DNSSEC verdict countersLennart Poettering
Also, don't consider RRs that aren't primary to the lookups we do as relevant to the lookups.
2016-01-25resolve: use different bitmap checking rules when we find an exact NSEC3 ↵Lennart Poettering
match, or just a covering enclosure If we are looking for a DS RR we need to check the NSEC3 bitmap of the parent zone's NSEC3 RR, not the one from the child. For any other RR we need to look at the child's however, hence enforce this with the bitmaps. Note that not coverign checks only the lower zone's NSEC3 bitmaps matter, hence the existing check is fine.
2016-01-18update DNSSEC TODOLennart Poettering
2016-01-18resolved: rework IDNA logicLennart Poettering
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs. Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix. With this change IDNA conversion is done only: - When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname() - When the user passes a non-ASCII domain suffix when resolving a service using ResolveService() No IDNA encoding is done anymore: - When the user does raw ResolveRecord() RR resolving - On the service part of a DNS-SD service name Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-17resolved: update DNSSEC TODOLennart Poettering
2016-01-17resolved: update RFCs list and TODO listLennart Poettering
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: properly look for NSEC/NSEC3 RRs when getting a positive wildcard ↵Lennart Poettering
response This implements RFC 5155, Section 8.8 and RFC 4035, Section 5.3.4: When we receive a response with an RRset generated from a wildcard we need to look for one NSEC/NSEC3 RR that proves that there's no explicit RR around before we accept the wildcard RRset as response. This patch does a couple of things: the validation calls will now identify wildcard signatures for us, and let us know the RRSIG used (so that the RRSIG's signer field let's us know what the wildcard was that generate the entry). Moreover, when iterating trough the RRsets of a response we now employ three phases instead of just two. a) in the first phase we only look for DNSKEYs RRs b) in the second phase we only look for NSEC RRs c) in the third phase we look for all kinds of RRs Phase a) is necessary, since DNSKEYs "unlock" more signatures for us, hence we shouldn't assume a key is missing until all DNSKEY RRs have been processed. Phase b) is necessary since NSECs need to be validated before we can validate wildcard RRs due to the logic explained above. Phase c) validates everything else. This phase also handles RRsets that cannot be fully validated and removes them or lets the transaction fail.
2016-01-11resolved: split up nsec3_hashed_domain() into two callsLennart Poettering
There's now nsec3_hashed_domain_format() and nsec3_hashed_domain_make(). The former takes a hash value and formats it as domain, the latter takes a domain name, hashes it and then invokes nsec3_hashed_domain_format(). This way we can reuse more code, as the formatting logic can be unified between this call and another place.
2016-01-11resolved: drop flags unused parameter from nsec3_is_goodLennart Poettering
2016-01-11basic: introduce generic ascii_strlower_n() call and make use of it everywhereLennart Poettering
2016-01-11resolved: use dns_answer_size() where appropriate to handle NULL DnsAnswerLennart Poettering
2016-01-11resolved: rename suffix_rr → zone_rrLennart Poettering
The domain name for this NSEC3 RR was originally stored in a variable called "suffix", which was then renamed to "zone" in d1511b3338f431de3c95a50a9c1aca297e0c0734. Hence also rename the RR variable accordingly.
2016-01-11resolved: fix NSEC3 iterations limit to what RFC5155 suggestsLennart Poettering
2016-01-06update DNSSEC TODOLennart Poettering
2016-01-05update DNSSEC TODOLennart Poettering
2016-01-05resolved,networkd: add a per-interface DNSSEC settingLennart Poettering
This adds a DNSSEC= setting to .network files, and makes resolved honour them.
2016-01-05resolved: rename "downgrade-ok" mode to "allow-downgrade"Lennart Poettering
After discussing this with Tom, we figured out "allow-downgrade" sounds nicer.
2016-01-05resolved: when caching negative responses, honour NSEC/NSEC3 TTLsLennart Poettering
When storing negative responses, clamp the SOA minimum TTL (as suggested by RFC2308) to the TTL of the NSEC/NSEC3 RRs we used to prove non-existance, if it there is any. This is necessary since otherwise an attacker might put together a faked negative response for one of our question including a high-ttl SOA RR for any parent zone, and we'd use trust the TTL.
2016-01-04update DNSSEC TODOLennart Poettering
2016-01-04resolved: partially implement RFC5011 Trust Anchor supportLennart Poettering
With this patch resolved will properly handle revoked keys, but not augment the locally configured trust anchor database with newly learned keys. Specifically, resolved now refuses validating RRsets with revoked keys, and it will remove revoked keys from the configured trust anchors (only until reboot). This patch does not add logic for adding new keys to the set of trust anchors. This is a deliberate decision as this only can work with persistent disk storage, and would result in a different update logic for stateful and stateless systems. Since we have to support stateless systems anyway, and don't want to encourage two independent upgrade paths we focus on upgrading the trust anchor database via the usual OS upgrade logic. Whenever a trust anchor entry is found revoked and removed from the trust anchor a recognizable log message is written, encouraging the user to update the trust anchor or update his operating system.
2016-01-04resolved: fix DNSSEC canonical ordering logicLennart Poettering
When applying canonical DNSSEC ordering for an RRset only order by the wire format of the RRs' RDATA, not by the full wire formatting. The RFC isn't particularly clear about this, but this is apparently how it is done. This fixes validation of pentagon.gov's DS RRset.
2016-01-03resolved: never authenticate RRsets with revoked keysLennart Poettering