[dns-operations] closest keys and validation policy
Ed.Lewis at neustar.biz
Sun Jul 18 15:23:57 UTC 2010
At 14:14 +0100 7/18/10, Jim Reid wrote:
>Rather than define these terms, can I suggest we encourage everyone to
>adopt the One True Path to DNSSEC, ie the trust anchor for the root, instead
>of kludging about with multiple trust anchors and ad-hoc validation schemes?
Why would we be "kludging about" with multiple this and ad-hoc that?
Because that is the very heart and soul of the extension's design
DNSSEC is a combination of the attestations of the publisher of the
zone and the use of these attestations by the receiver to decide if
the receiver will accept the learned information. First and
foremost, DNSSEC is for the protection of the recipient. Protection
of the sender is not the primary goal.
If DNSSEC was designed to take a strictly tree-based approach to
security, why would the owner of the key need to be identified in the
RRSIG? The original designers recognized that security makes a
resilient system brittle, there had to be multiple ways for a
recipient to be able to learn to trust data.
Remember "local policy" trumps all other stated policies. It's about
protection of the cache from cache poisoning. That's why.
In particular, debating a trust anchor that is hard coded in a name
server versus the live root chain - sure it might be the case that
the trust anchor might be out of date and therefore only the root
chain should be trusted. But if you are cut off from the global
public Internet a local trust anchor may be all you have.
NeuStar You can leave a voice message at +1-571-434-5468
Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
More information about the dns-operations