feat: DNSSEC Validation #470
Conversation
developStorm
force-pushed
the
refactor/generic-cache
branch
from
63f8763 to
414dc59
Compare
dnssec related functions now sit in their own file
revert depth change. depth can't be carried to subqueries
developStorm
force-pushed
the
feat/basic-dnssec-validation
branch
from
d907ca8 to
4d62421
Compare
|
Additionally, let's add integration tests to |
developStorm
force-pushed
the
feat/basic-dnssec-validation
branch
from
2d4c764 to
148eb28
Compare
It seems cloudflare will not validate anything with iteration > 0. We are fine validating them, but print a log for visibility.
|
I conducted another round of tests on the top 10k domains, and the results aligned closely with Cloudflare, with a few explainable non-alignments remain:
I'm comfortable with the shape of this PR now. Feel free to start reviewing @phillip-stephens @zakird. |
There was a problem hiding this comment.
Overall this look great and I'm very excited to see DNSSEC validation added. @phillip-stephens is going to take a closer look.
|
Re 1: This might be worth fixing in ZCrypto and using that. I think that we can leave this however as a FR and merge in any case. |
There was a problem hiding this comment.
LGTM, I tested it locally on 1k domains and spot-checked a few of them. Also reverted the change to require go 1.20 since not sure we need to do that. Otherwise this looks really great and super excited about it! Thanks @developStorm!
resolves #441
Purpose
Adds support for validating DNSSEC records up to the root's chain-of-trust
The level of detail in the validation results depends on the
--result-verbosity=flag. In theshortmode, validation results are not output (equivalent to no validation). In thenormalmode, only the overall validation status is output. In thelongmode, all relevant records used for validating this specific result (DS, DNSKEY, RRSIG) and the validation results for each individual RRset are printed. In thetracemode, all validation details for the entire query chain are available along the trace.Since we are a DNS scanning tool, the resolution results may still hold value even in cases of DNSSEC validation failure. Therefore, a validation failure does not lead to a resolution failure - i.e., the resolution results will still be output normally. It is the responsibility of data consumers to check the DNSSEC validation status before using the results.
Example usage:
go run . A example.com --iterative --validate-dnssec --result-verbosity=longExample output (long):
{ "class": "IN", "name": "example.com", "results": { "A": { "data": { "answers": [ { "answer": "93.184.215.14", "class": "IN", "name": "example.com", "ttl": 3600, "type": "A" }, { "algorithm": 13, "class": "IN", "expiration": "20241206041826", "inception": "20241115121713", "keytag": 60915, "labels": 2, "name": "example.com", "original_ttl": 3600, "signature": "vRP5fmIUOIHdIXJsnFkSLYL84OEh4isvOeIkPdGR1Ro+YUs4tTNO6J3ajnDvcIZfc5p+j8R35Z/SOOqD9ZY95w==", "signer_name": "example.com.", "ttl": 3600, "type": "RRSIG", "type_covered": 1 } ], "dnssec": { "additionals": [ { "error": "", "rrset": { "class": 4096, "name": ".", "type": 41 }, "sig": null, "status": "Insecure" } ], "answer": [ { "error": "", "rrset": { "class": 1, "name": "example.com.", "type": 1 }, "sig": { "algorithm": 13, "class": "IN", "expiration": "20241206041826", "inception": "20241115121713", "keytag": 60915, "labels": 2, "name": "example.com", "original_ttl": 3600, "signature": "vRP5fmIUOIHdIXJsnFkSLYL84OEh4isvOeIkPdGR1Ro+YUs4tTNO6J3ajnDvcIZfc5p+j8R35Z/SOOqD9ZY95w==", "signer_name": "example.com.", "ttl": 3600, "type": "RRSIG", "type_covered": 1 }, "status": "Secure" } ], "authoritative": [ { "error": "", "rrset": { "class": 1, "name": "example.com.", "type": 2 }, "sig": { "algorithm": 13, "class": "IN", "expiration": "20241206020003", "inception": "20241115121713", "keytag": 60915, "labels": 2, "name": "example.com", "original_ttl": 86400, "signature": "9W8bAJT/4vA3nH8QU/NeM1n8bZZWn5PBkN26ix827VQGWY0YdMniks/1YCIaVNl16xly4s5IsVDtI9rLvaZORw==", "signer_name": "example.com.", "ttl": 86400, "type": "RRSIG", "type_covered": 2 }, "status": "Secure" } ], "dnskey": [ { "algorithm": 13, "class": "IN", "flags": 256, "name": "example.com", "protocol": 3, "public_key": "ai2pvpijJjeNTpBu4yg6T375JqIStPtLABDTAILb+f4J7XpofUNXGQn6FpQvZ6CARWn2xQapbjGtDRjTf4qYxg==", "ttl": 3600, "type": "DNSKEY" } ], "ds": [ { "algorithm": 13, "class": "IN", "digest": "be74359954660069d5c63d200c39f5603827d7dd02b56f120ee9f3a86764247c", "digest_type": 2, "key_tag": 370, "name": "example.com", "ttl": 3600, "type": "DS" } ], "status": "Secure" }, "flags": { "authenticated": false, "authoritative": true, "checking_disabled": false, "error_code": 0, "opcode": 0, "recursion_available": false, "recursion_desired": false, "response": true, "truncated": false }, "protocol": "udp", }, "duration": 1.072630625, "status": "NOERROR", } } }Example output (normal):
{ "name": "example.com", "results": { "A": { "data": { "answers": [ { "answer": "93.184.215.14", "class": "IN", "name": "example.com", "ttl": 3600, "type": "A" }, { "algorithm": 13, "class": "IN", "expiration": "20241206041826", "inception": "20241115121713", "keytag": 60915, "labels": 2, "name": "example.com", "original_ttl": 3600, "signature": "vRP5fmIUOIHdIXJsnFkSLYL84OEh4isvOeIkPdGR1Ro+YUs4tTNO6J3ajnDvcIZfc5p+j8R35Z/SOOqD9ZY95w==", "signer_name": "example.com.", "ttl": 3600, "type": "RRSIG", "type_covered": 1 } ], "dnssec": { "status": "Secure" }, "protocol": "udp" }, "duration": 0.803631958, "status": "NOERROR" } } }