validator repeatedly checks insecurity proofs for insecure domains
Summary
It seems that DNSSEC validator rechecks insecurity proofs several times while processing answer from an insecure domain.
BIND version used
- main: 2c3eea19
Steps to reproduce
- Increase logging for validator. I've used this patch: log.patch
- Query for a subdomain of an insecure domain:
dig a.b.c.d.e.f.google.com
- Query for another subdomain:
dig 0.b.c.d.e.f.google.com
- Check logs
What is the current bug behavior?
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: starting
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: attempting negative response validation from message
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: validate_neg_rrset: creating validator for google.com SOA
20-Jul-2022 16:20:23.334 validating google.com/SOA: starting
20-Jul-2022 16:20:23.334 validating google.com/SOA: attempting insecurity proof
20-Jul-2022 16:20:23.334 validating google.com/SOA: checking existence of DS at 'com'
20-Jul-2022 16:20:23.334 validating google.com/SOA: checking existence of DS at 'google.com'
20-Jul-2022 16:20:23.334 validating google.com/SOA: marking as answer (proveunsecure (4))
20-Jul-2022 16:20:23.334 validator @0x7f1c4d264400: dns_validator_destroy
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: in validator_callback_nsec
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: resuming validate_nx
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: nonexistence proof(s) not found
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: checking existence of DS at 'com'
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: checking existence of DS at 'google.com'
20-Jul-2022 16:20:23.334 validating _.f.google.com/A: marking as answer (proveunsecure (4))
20-Jul-2022 16:20:23.334 validator @0x7f1c4d263a00: dns_validator_destroy
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: starting
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: attempting negative response validation from message
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: validate_neg_rrset: creating validator for google.com SOA
20-Jul-2022 16:20:23.371 validating google.com/SOA: starting
20-Jul-2022 16:20:23.371 validating google.com/SOA: attempting insecurity proof
20-Jul-2022 16:20:23.371 validating google.com/SOA: checking existence of DS at 'com'
20-Jul-2022 16:20:23.371 validating google.com/SOA: checking existence of DS at 'google.com'
20-Jul-2022 16:20:23.371 validating google.com/SOA: marking as answer (proveunsecure (4))
20-Jul-2022 16:20:23.371 validator @0x7f1c4d264400: dns_validator_destroy
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: in validator_callback_nsec
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: resuming validate_nx
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: nonexistence proof(s) not found
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: checking existence of DS at 'com'
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: checking existence of DS at 'google.com'
20-Jul-2022 16:20:23.371 validating 0.b.c.d.e.f.google.com/A: marking as answer (proveunsecure (4))
20-Jul-2022 16:20:23.371 validator @0x7f1c4d263000: dns_validator_destroy
This is probably related to fact that validation proceeds "down" even if parent zone is proved to be insecure. This can be seen e.g. on dualstack.osff2.map.fastly.net A
query. I would expect it to stop doing things at fastly.net DS
level.
What is the expected correct behavior?
I would expect the validation to be cut soon on checking existence of DS at 'com'
. In the log excerpt for google.com subdomains it repeats three times, along with insecurity proofs for domains we should be marked as insecure in cache (b.c.d.e.f.google.com
and everything up to google.com
.)
Relevant configuration files
Default config.