| Age | Commit message (Collapse) | Author |
|---|
|
the DNSKEY's algorithm
As long as we support the digest we are good.
|
|
name, not the owner name
When the DNSKEY is in higher zone, then that's OK, and we need to check
the RRSIG's signer name against the DNSKEY hence.
|
|
We actually maintain an array of pointers to RRs, not of RRs themselves,
fix the qsort() invocation accordingly.
|
|
libgcrypt encodes the error source in the error code, we need to mask
that away before comparing error codes.
|
|
|
|
|
|
files for now
|
|
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.
|
|
|
|
|
|
RSASHA1_NSEC3_SHA1 is an alias for RSASHA1, used to do NSEC3 feature
negotiation. While verifying RRsets there's no difference, hence support
it here.
|
|
|
|
This adds most basic operation for doing DNSSEC validation on the
client side. However, it does not actually add the verification logic to
the resolver. Specifically, this patch only includes:
- Verifying DNSKEY RRs against a DS RRs
- Verifying RRSets against a combination of RRSIG and DNSKEY RRs
- Matching up RRSIG RRs and DNSKEY RRs
- Matching up RR keys and RRSIG RRs
- Calculating the DNSSEC key tag from a DNSKEY RR
All currently used DNSSEC combinations of SHA and RSA are implemented. Support
for MD5 hashing and DSA or EC cyphers are not. MD5 and DSA are probably
obsolete, and shouldn't be added. EC should probably be added
eventually, if it actually is deployed on the Internet.
|
