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

[Mark Andrews]

> At 0:29 +1100 2/19/08, Mark Andrews wrote:
> 
> >	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.
> 
> The first RFC on DNSSEC appeared before thought was given to 
> deployment. I.e., the design that includes AD, CD, etc., was cemented 
> before any thought was given to initial deployment.  The DO bit came 
> later, in response to a problem in our "eating our own dog food," to 
> name one early tweak that was done in the name of deployment.
> 
> During the first years of DNSSEC development we were completely 
> absorbed with the issues relating to applying cryptography.  A bigger 
> issue was that the keys be off-line for safety, all signatures 
> pre-generated to remove the processing load from the authoritative 
> servers.  We were also cognizant that most application-running 
> devices lacked the resources to perform public key cryptography.  Not 
> too mention that a large issue was the RSA patent and export control 
> laws.
> 
> >	DNSSEC does NOT require TSIG or SIG(0).  Never has and never
> >	will require them.  TSIG and SIG(0) are NOT DNSSEC.
> 
> Alternatives include VPNs, SSH tunnels, strict network-layer 
> filtering (firewalls), and so on.  The point is that DNSSEC's scope 
> is limited to the DNS to DNS server; it must still be augmented to 
> cover delivery to the stubs.

	No. DNSSEC's scope was never limited to DNS server to DNS server.

	It has always been zone to resolver.  Please go and re-read
	RFC 2065 Section 2.3 Data Origin Authentication and Integrity

	Under your interpretation if I implement DNSSEC in a iterative
	resolver that's not part of a recursive nameserver I'm stepping
	outside to the scope of the RFC's.  That's total rubbish.

	Under your interpretation if I implement DNSSEC using a
	stub resolver I'm stepping outside to the scope of the RFC's.
	That also is total rubbish.
 
	The application MAY CHOOSE to let the recursive server do
	the validation on its behalf.  It is not REQUIRED to however.
	If you look at RFC 2065, letting the recursive server do
	the validation on its behalf was a "MAY".

	You keep confusing application choices with protocol contraints.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org