On 11/2/17, 11:27, "DNSOP on behalf of Warren Kumari" <dnsop-boun...@ietf.org on behalf of war...@kumari.net> wrote: > Having a (per-TA) knob sounds like a nice compromise, but I'd really > like implementors to chime in on how much complexity this adds. If *I* > added a local TA for .example (or foo.example.com) I'd automatically > assume that this is a closest encloser / Negative Trust Anchor / > longest match type operation and would be very surprised if that > wasn't the behavior -- this *may* be a combination of being primarily > a routing person, and also the fact that if I create a local zone for > foo.example.com (in a non-DNSSEC world) I'd expect it to take > priority...
This is an interesting viewpoint. I understand that in the routing world, longest match prefix is the way the outgoing interface is chosen. This doesn't translate into the design of DNSSEC though. (Like a pun in English isn't quite the same in any other language and vice versa.) The issue in routing is that you have to choose one solution and go with it. Unless you are multi/broadcasting, the packet is going to go on to one outgoing buffer/queue. The issue in DNSSEC is to retain as much robustness as possible because the decision will have a long-lasting impact (sitting in cache, opening an ssh connection, etc.) This mirrors what Paul said in an earlier message regarding PKIX. On 11/2/17, 11:11, "DNSOP on behalf of Paul Hoffman" <dnsop-boun...@ietf.org on behalf of paul.hoff...@vpnc.org> wrote: >The consensus conclusion was that any performance penalty was worth the >consistency of answers, since the relying part (the stub resolver in our case) >had no control over the order of evaluation. Consistency is the objective there, not robustness, but I'd hand-wave the two are closely related. Consistency, in terms of coherence, has historically been part of the DNS rhetoric, which (I'll claim) is a/one foundation for DNSSEC's robustness. So, I get that from a routing backdrop, the longest match expectation is reasonable but not what was written into the DNSSEC documents because DNS and DNSSEC have different objectives than routing (or forwarding, whichever is more appropriate).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
