[dns-operations] Implementation of negative trust anchors?
marka at isc.org
Fri Aug 23 22:03:42 UTC 2013
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.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations