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
Have this super weird case where additionals from dnssec-tools.org contains an A and RRSIG for each of (nsm|nsw).dnssec-tools.org. If identify by only type, these two will be clustered under the same set and could not validate.
|
What have we done to test this? Can we run this against the top million websites or such and see how it goes? A lot of code. |
At this point it's just manual and unit tests performed against the above domains shared by Phillip, and I monitored request sanity with Wireshark. I can look into large scale test later. |
This reverts commit 2b074a2.
| @@ -67,6 +67,7 @@ type QueryOptions struct { | |||
| ClassString string `long:"class" default:"INET" description:"DNS class to query. Options: INET, CSNET, CHAOS, HESIOD, NONE, ANY."` | |||
| ClientSubnetString string `long:"client-subnet" description:"Client subnet in CIDR format for EDNS0."` | |||
| Dnssec bool `long:"dnssec" description:"Requests DNSSEC records by setting the DNSSEC OK (DO) bit"` | |||
| ValidateDNSSEC bool `long:"validate-dnssec" description:"Validate DNSSEC records, only applicable with --iterative"` | |||
There was a problem hiding this comment.
I think we discussed allowing this even when not in `--iterative``.
| DS []*DSAnswer `json:"ds" groups:"dnssec,long,trace"` | ||
| DNSKEY []*DNSKEYAnswer `json:"dnskey" groups:"dnssec,long,trace"` | ||
| Answer []DNSSECPerSetResult `json:"answer" groups:"dnssec,long,trace"` | ||
| Additionals []DNSSECPerSetResult `json:"additionals" groups:"dnssec,long,trace"` |
There was a problem hiding this comment.
I think this should be Additional not Additionals per RFC and in matching the other types.
resolves #441
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" } } }