[dnssec-deployment] AP: "Use of Rogue DNS servers on rise"

[Mark Andrews]

> At 18:31 +1100 2/18/08, Mark Andrews wrote:
> 
> >	DNSSEC is designed to protect to the application.  Whether
> >	it is used that way remains to be seen.
> 
> No, no, it isn't.  If that were true, we would have never designed 
> message integrity mechanisms.  We would have never defined the AD and 
> CD bits.

	CD was designed to let the application get the data through
	a resolver with a different set of trust anchors and/or
	different policy and/or bad clock and/or any other reason
	that can cause a validation failure.

	AD is there for applications that wish to offload validation
	to the caching resolver for particular policy subsets which
	fit with the use of AD.

	The initial deployment was expected to be caching resolvers
	to protect applications that don't implement DNSSEC.  Long
	term deployment expected applications to become DNSSEC
	aware.  AD is a long way from full DNSSEC awareness.
 
> When DNSSEC was designed and redesigned, it was supposed to mimic the 
> actions of the unprotected DNS.  I.e., the use of caches.  Just as 
> caches are a way to limit the times a "site" goes to a authoritative 
> server and limits the times when nodes of the site have to go beyond 
> the cache, DNSSEC validation was thought to be located at the caches. 
> Just like any application can do DNS iteration, an application can do 
> DNSSEC.  But because we defined DNSSEC to be like DNS, we also then 
> added the "last hop" mechanisms.
> 
> TSIG and SIG(0) only say that the message between the stub (client) 
> and the first responder (cache) transferred untouched.  CD means 
> "don't do DNSSEC for me" which was needed because we assumed 
> otherwise the first responder would only return what it thought was 
> good.  (Think "clock skew" for one.)  And AD means the first 
> responder checked and according to it's policy, the data entered the 
> server good.

	DNSSEC does NOT require TSIG or SIG(0).  Never has and never
	will require them.  TSIG and SIG(0) are NOT DNSSEC.

	If you wish to let the caching resolver validate answers for
	you then is it recommend that you secure the path between the
	stub resolver and the caching resolver.  TSIG and SIG(0) can
	be used for that but are not required to be used for that.

> If we thought that DNSSEC was protecting out to the application, we 
> would not have put validation in the caches.  We would not assume 
> that caches were going to check.  We would have dropped cache's doing 
> validation because for a while running NTP on a DNS server was a 
> novelty.

	The cache needs to protect itself.  This is not mutually
	exclusive with the application also wanting to protect
	itself, or with it fetching data through a cache.
 
> Anytime we've tried to mission creep the intention of DNSSEC we got 
> slapped back.  (Remember SIKED BOF?  See what happened when signing 
> the root meant more than just getting the data transfers to be 
> secure?)  DNSSEC (RFC 4033-4035) is only server to server.

	No.  DNSSEC has never been just server to server.  DNSSEC
	has been ensuring that the data that was signed is what is
	delivered and that attempts to modify that data are detected.

> We spent a long time dealing with the sematics of DNSSEC in user 
> interfaces like HTML renderers. It was apparent that DNS'ers are not 
> the best group to say what's right for applications.  It would be a 
> design mistake to have proposed an extension to DNS that would 
> provide security to applications.  The best we can do is to offer to 
> the applications data that got to the fringes of the DNS "safely."
	
	You obviously think I was meaning more by "protect the
	application" than ensuring that the data gets through without
	being compromised.  I'm well aware of DNSSEC's strengths
	and limitations.

	Mark

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Mail archives, backups.  Sometimes I think the true beneficiaries of
> standards work are the suppliers of disk drives.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org