On 03 Dec 2013, at 10:06, Tony Finch <d...@dotat.at> wrote: > Mark Andrews <ma...@isc.org> wrote: >> Tony Finch <d...@dotat.at> wrote: >>> Roy Arends <r...@dnss.ec> wrote: >>> >>>> If that succeeds, only then validation makes sense. >>> >>> Why? Why not validate the chain of referrals as you follow them? The >>> protocol is designed to support that otherwise it would not include the DS >>> in the referral. >> >> It's more because we havn't coded for it yet, especially the non >> existence case, than anything else. > > Yes, and that's perfectly fine :-) I'm just puzzled why Roy thinks it > doesn't make sense to reduce validation latency.
I said "I agree there is some room for optimisation, using previously obtained information (like the DS record and its signature) to complete the validation chain, which has a complexity cost as well.” The additional complexity hasn’t been added yet, and I highlighted some of the corner cases that comes with it, if it would be added. i.e. I never said that it doesn’t make sense to reduce validation latency. On the contrary. I also said that it makes sense to complete the delegation chain first, then complete the validation chain. To be clear, I’m all for reducing validation latency. Hence if there is stuff to validate and the keys are there, go for it. If the keys (or DS records) are not yet present, I’d prioritise getting the records in for the delegation chain before getting the records for the validation chain. If there is no complete delegation chain (something is lame), SERVFAIL early on it. The client might not care about validation (CD=1). > I'm also wondering what the advantages are to bottom-up validation. It > gets really knotty when the leaf records have broken signatures - you > have to keep walking up the tree to see if there's an insecure delegation > to work out whether to return bogus or insecure. I don’t think it actually matters, (bottom-up vs top-down). It is simply a chain of TA-DNSKEY-(DS-DNSKEY)-ANSWER. Since DNSKEYs have to be explicitly queried for (and sometimes DS records), just fill them in. You can issue a set of queries for all the missing DNSKEYs in parallel (not waiting for one to finish before issuing the second missing DNSKEY/DS). It is then either complete or not. If not, all bets are off. I personally don’t like the effect of querying all authoritative servers for a single zone in order to get a proper validation path, and then backtracking to get an alternative delegation path. That leads to the “Rollover and Die” issues we saw a couple of years ago. Roy
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
