[dns-operations] Implementation of negative trust anchors?

[Mark Andrews]

In message <52179660.7000604 at digsys.bg>, Daniel Kalchev writes:
> 
> On 23.08.13 19:57, Ralf Weber wrote:
> > Moin!
> >
> > On 23.08.2013, at 09:19, Paul Vixie <paul at redbarn.org> 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
> dns-operations at lists.dns-oarc.net
> 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: marka at isc.org