In message <[email protected]>, Daniel Kalchev writes: > > On 23.08.13 19:57, Ralf Weber wrote: > > Moin! > > > > On 23.08.2013, at 09:19, Paul Vixie <[email protected]> wrote: > >> if nasa.gov had screwed up its delegation or had allowed its public second > ary servers to expire the zone due to primary unreachability, i do not think > the phone at comcast would have rung less, but i also don't think that comcas > t would have fixed nasa's error in local policy. we're only talking about thi > s because DNSSEC is new. > > There is huge difference between DNS outages caused by connectivity and DNS > SEC caused outages. Without DNSSEC screwing up your domain so badly that it i > s unreachable is very very hard. With DNSSEC you make one small error and you > r domain goes dark for those who validate. Given that the cost of this is not > on the domain owner, but instead on the service providers that validate. I t > hink it is absolutely needed to give them a tool to minimize these costs (NTA > ). > > > > Paul is correct. Everyone blames DNSSEC, because it is new. > > When you learn DNSSEC procedures and master them, you will discover it > is not "easy" to screw up DNSSEC either. > > Once upon a time people were afraid to fly. Today they happily line up > at airport gates. > > What is absolutely needed is to move the validation to the stub resolver > and remove it from the caching resolver that is operated by a "service > provider". Any service provider will attempt to cut costs, at any price. > No need to put the burden of validating DNSSEC on the resolver, as they > don't have any use of this -- when stubs validate, cache corruption is > not even a problem.
No. Validation needs to be in *both* the resolver and the stub. Anyone who says otherwise really does not understand DNSSEC. A validating stub resolver cannot work reliably in the face of a deliberate attack unless the recursive server is also validating. Can we please stop propogating this myth that rescursive servers don't need to validate when stubs do. Mark > Daniel > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
