[dns-operations] why lookaside is not evil

Edward Lewis Ed.Lewis at neustar.biz
Fri Mar 26 01:56:11 UTC 2010


At 17:49 -0700 3/25/10, Phil Pennock wrote:

>My understanding is that the long-term goal is to not have look-aside
>mechanisms and that all trust anchors will be in-tree, starting at the
>root.

When DNSSEC was originally defined, requiring the trust-anchors to be 
in-tree was explicitly a non-goal.  We wanted and wished to allow 
flexibility in the way a validator could establish confidence in the 
response.

To support this assertion you can see this in the number and dates of 
RFCs. RFC 2065 contains the first definition of the signature 
containing resource record.  In it there are two fields dedicated to 
identifying the key generating the signature.  One field is the 
domain name owning the key.  It wasn't until RFC 3007 that in-tree 
signing was defined to be the default authorization model.  RFC 3007 
is dated three years after RFC 2065.

One of things that transpired in the three intervening years was the 
realization that the computational complexity involved with a 
generalized policy was too great for the DNS to handle.  With a 
sufficiently complex policy, a malicious agent could cause a 
validator to go into computational loops, leading to a denial of 
service.  In addition, generating a policy specification language was 
just too much work.  So we declared "failure" on this and generated 
RFC 3007.

The reason for the desired flexibility is that when you extend a 
system to be more secure you will naturally make it more brittle.  To 
counter act the drop in resiliency that results from this you need to 
make the security system more agile.  Who to trust and how to gain 
trust are more flexible if they have choices, but as mentioned in the 
previous paragraph, the decision making process required when you 
have choices can be exploited.

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

New pithy statement under construction...



More information about the dns-operations mailing list