At 11:19 -0400 4/21/11, Paul Wouters wrote:
But you can only get here if you had followed the new glue at the TLD, validated the new NS set at the new operator, using its new DNSKEY set, for which you would need the new DS. So by the time you're passed the NS set, you have all the DNSKEY's needed for other zone content.
You don't have to pre-validate hints (referrals). In fact, it's better if you don't.
The situation described in the draft cannot happen for proper validators.
I'd design a validating iterative resolver to be goal-directed and thus depth-first. As one traverses from the root (or last cached point) to the answer, relying on optimism is expedient. Once you get the suspected answer and then apply validation - if the result validates what does it matter if you got there through some shady paths?
Once the answer is delivered to the client, then it is wise to spend time validating and caching the hints.
If the suspected answer doesn't validate, then it's time to become pessimistic and chunk down the tree via validated referrals. This is the approach I used when writing an early version of a validator (i.e., back in the 20th century).
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
