On 11/06/13 23:26, Ewen McNeill wrote:
On 2013-06-11 22:40 , Sebastian Castro wrote:
> You just touched a very sensitive nerve. One of the missing parts of the
> DNSSEC ecosystem is how to guarantee the validating resolver is playing
> nice. Because the current protocol only provides a one-bit flag to
> signal if the data was authentic or not, a non-cooperative resolver can
> simply lie and tell you... "yeah, this data is valid, see the flag?"
Thank Ewen for this, you are covering three interesting problems:
1) How do you establish and keep trust on your resolver
2) How do you know if your resolver is not lying to you
3) How to protect from traffic between you and your resolver is not
If you don't have external reasons to fully trust the validating
resolver (ie, it might lie to you, or the responses might be altered in
between the validating resolver and the application), _and_ you don't
check the trust chain from known good root information, then yes,
something in the path could lie to you.
There isn't any obvious solution to that which doesn't involve checking
a chain of trust in-application. The validating resolver providing more
than a one bit flag stating it has checked it, and it's "all good guv",
doesn't help: it can still lie, no matter how you dress that up. Without
an external reference, you have the self-signed-certificate problem: in
order to trust it, you have to trust it.
Basically if your "validating resolver" is outside the host you are
running on, you're at most crossing your fingers and hoping for the best
if you delegate verifying DNSSEC to something else. If the resolver
you're trusting is "outside your AS" (eg, upstream provider), you'll
need a bunch more fingers to cross (there's a lot of untrusted network
This is an example of issue 3 noted above. For this, for example,
OpenDNS proposed a solution called DNSCrypt
Running a validating resolver locally has been the trend lately, but
it's a practice that's limited to hosts with some computing power, for
example, doesn't sound like a good idea on a smartphone because it will
increase the power consumption.
On the matter of locally-running resolver, NLnetLabs (the same authors
of unbound) have this project called dnssec-trigger to have validation
on your host: http://www.nlnetlabs.nl/projects/dnssec-trigger/
Either you really care that the DNSSEC is valid, in which case you
validate it yourself (in application), from the root. And do something
meaningful in the case of (apparent) subterfuge. Or you accept that
what you have is at best "a (tiny) bit better than what you had before"
and life goes on. External validating resolvers are, at best, a
stepping stone on the path towards full DNSSEC deployment. A necessary
step in practice, I think. But they can lie to you too. All you've
done is moved your "point of total faith" a bit closer to you.
Effectively we are making little gains at every step, but still we are
not totally there with solutions for all the issues. There a lot of work
to do :)
PS: In a fully checking DNSSEC world these DNS tricks (forged data) may
well end up being equivalent to "not answering". Which is also an
option today. It's just likely to cause more helpdesk calls stating
"the Internet is broken". So much as I too dislike forged data, if the
choice is "no answer, it's broken" and "forged data, point at a
saying it's broken" I'd probably lean towards forged data too.
 Having, eg, a SSL key for the validating resolver doesn't stop it
lying -- it just helps you avoid listening to others lie to you: you
gain some certainty on where the lies are coming from.... which helps
with attribution, but not with certainty you're not being lied to.
 Maybe you're even crossing your fingers if the validating resolver
is on the same host; but if the intruder is in your host, affecting what
the validating resolver says, you probably have bigger problems.
NZNOG mailing list
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535