[Dnssec-deployment] DNSSEC aware recursive name servers

[Edward Lewis]

At 10:04 +1000 8/6/11, Mark Andrews wrote:

>DNSSEC is there to protect the data end to end.  Caches are just one
>consumer of the data.

Source authenticity, data integrity, authenticated negative answers - 
are the goals.

End to end protection would be nice, but that clearly wasn't in the 
original plans.  What we began with was a system that had "dumb" end 
elements - the stubs.  It's easy to confuse "source authenticity" and 
"end-to-end" because they seem to be the same whatever your 
perspective sits.

I don't mean to come across as saying that DNSSEC's origin was this 
and should never be changed.  I'm pointing out the original plan was 
to be something.  If now we imagine the goal is something different 
don't be frustrated that the extensions don't see to fit the need.

This thread started with the supposition that the placement of the DS 
record at the parent was a design flaw.  I'm pointing out that this 
wasn't a flaw at all, it supports what the extensions were meant to 
do.  My defense is not personal - Olafur proposed the DS record and 
when he did I jokingly told him one of my objections is that "it came 
from Olafur."  My defense is trying to make sure we collectively know 
why things are the way they are and not wander off into a land of 
folklore. The term "revisionist history" is a strong statement but it 
kind of describes what I want to prevent.  We need to maintain an 
accurate history, even if we re-interpret what we see.  (I looked at 
my NANOG 19 presentation [sometime in 2000] and see places where I 
made mistakes in explaining DNSSEC back then, because we revised how 
we viewed it.)

As far as applications doing their own validation, I don't have high 
hopes that that will work out.  Based on my observations and what I 
see coming, I have reservations.  People are welcome to make attempts 
at gluing validation into applications and there will be some 
successes.  But I'm not very optimistic.

In the meantime, just be aware of what DNSSEC was designed to do and 
expect to be fighting entropy to go beyond the original problem set.

PS - I finally came up with something I would have changed in the 
original design.  Olafur and I talked about this, he had a similar 
change in mind.  Our suggestions differed but both would have 
amounted to an extra field in the RRSIG that indicated the size of 
the plaintext signed.  I think I would have counted records, he 
counted bytes.  The reason for this was one more protection against a 
weakness in hash algorithms.  Beyond that, any alteration would 
result in a tradeoff against some other feature.

PPS - Before NSEC3 came out I posted the decision tree that drove us 
to pick the design of NSEC.  My statement was that to achieve what 
became NSEC3 we'd have to undo one of the decisions - which is what 
happened.  (E.g., NSEC3 and zones with wild cards don't quite get 
along.)  Hey, it's possible to make different decisions but they come 
at a cost.  Every choice is a tradeoff.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.