[dnssec-deployment] AP: "Use of Rogue DNS servers on rise"
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
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