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

Edward Lewis Ed.Lewis at neustar.biz
Mon Feb 18 18:36:31 EST 2008

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 

>	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.

>	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.

That idea has caused considerable debate.  Today caches don't really 
protect themselves, they cache answers whether they validate or not. 
The distinction between data that validate and that which didn't is 
made when using the data in a response.  At one time caches only 
saved validated answers, then we realized that such a restriction was 
a vulnerability to a DoS situation - a client could repeatedly ask 
for data that failed the same validation over and over.  The client 
need even be malicious, just mystified by SERVFAIL.

>	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.

DNSSEC does not ensure that the data as signed is what is delivered, 
e.g., DDoS is not countered by DNSSEC.  Man in the middle answer 
substitution would need to be addressed by the DNSSEC client, having 
to keep accepting answers until one verified - if the goal of DNSSEC 
was guaranteed delivery.

DNSSEC adds ancillary data so that the receiver can verify that the 
data was unmodified.  It's possible to put a validator in something 
other than a DNS server, but it's just not done (maybe there are some 
examples, but they are probably not mainstream).  Why?  I'm not an 
application developer, but I have my hunches.

>	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.

It's not a matter of knowing the strengths and weaknesses of DNSSEC, 
it's a matter of clearly describing the mechanism's abilities. E.g., 
"without being compromised" might mean "without disclosure (of secret 
information)."  DNSSEC does not obfuscate data, but to someone who 
does deal with data requiring confidentiality that is what 
"compromise" means.

Edward Lewis                                                +1-571-434-5468

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

More information about the Dnssec-deployment mailing list