summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-trust-anchor.c
AgeCommit message (Collapse)Author
2015-12-18resolved: add support NSEC3 proofs, as well as proofs for domains that are ↵Lennart Poettering
OK to be unsigned This large patch adds a couple of mechanisms to ensure we get NSEC3 and proof-of-unsigned support into place. Specifically: - Each item in an DnsAnswer gets two bit flags now: DNS_ANSWER_AUTHENTICATED and DNS_ANSWER_CACHEABLE. The former is necessary since DNS responses might contain signed as well as unsigned RRsets in one, and we need to remember which ones are signed and which ones aren't. The latter is necessary, since not we need to keep track which RRsets may be cached and which ones may not be, even while manipulating DnsAnswer objects. - The .n_answer_cachable of DnsTransaction is dropped now (it used to store how many of the first DnsAnswer entries are cachable), and replaced by the DNS_ANSWER_CACHABLE flag instead. - NSEC3 proofs are implemented now (lacking support for the wildcard part, to be added in a later commit). - Support for the "AD" bit has been dropped. It's unsafe, and now that we have end-to-end authentication we don't need it anymore. - An auxiliary DnsTransaction of a DnsTransactions is now kept around as least as long as the latter stays around. We no longer remove the auxiliary DnsTransaction as soon as it completed. THis is necessary, as we now are interested not only in the RRsets it acquired but also in its authentication status.
2015-12-03resolved: add a simple trust anchor database as additional RR sourceLennart Poettering
When doing DNSSEC lookups we need to know one or more DS or DNSKEY RRs as trust anchors to validate lookups. With this change we add a compiled-in trust anchor database, serving the root DS key as of today, retrieved from: https://data.iana.org/root-anchors/root-anchors.xml The interface is kept generic, so that additional DS or DNSKEY RRs may be served via the same interface, for example by provisioning them locally in external files to support "islands" of security. The trust anchor database becomes the fourth source of RRs we maintain, besides, the network, the local cache, and the local zone.