[Dnssec-deployment] DNSSEC aware recursive name servers
Ed.Lewis at neustar.biz
Fri Aug 5 21:45:27 EDT 2011
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
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.
NeuStar You can leave a voice message at +1-571-434-5468
I'm overly entertained.
More information about the Dnssec-deployment