To:
dnssec@cafax.se
From:
Michael Richardson <mcr@sandelman.ottawa.on.ca>
Date:
Mon, 10 May 2004 17:32:25 -0400
In-Reply-To:
Message from David Blacka <davidb@verisignlabs.com> of "Mon, 10 May 2004 15:48:48 EDT." <200405101548.48640.davidb@verisignlabs.com>
Sender:
owner-dnssec@cafax.se
Subject:
Re: dnssec: resolver - application communication
-----BEGIN PGP SIGNED MESSAGE-----
{my appologies for reordering}
>>>>> "David" == David Blacka <davidb@verisignlabs.com> writes:
David> But the SASR shouldn't even know *how* to bypass the cache.
I agree strongly.
That's why I want the security-aware caching resolver to return more
information on a failure. I hope in 99% of the cases, this channel will
be local, so 64K UDP packets (or UNIX domain packet, or named-pipes)
should be fine.
David> It is true that a SASR cannot get away with the brain-dead
David> simple mode of operation that a non-SASR can. Instead of
David> one-call->one-query->one-response, the SASR must follow the
David> original response with queries for the other data that it
David> needs to do the validation (that is, the chain-of-trust
David> information). This isn't so bad, because 99 times out of
David> 100, this information will be coming from the full resolver's
David> cache, as the full resolver probably just cached it. If the
David> SASR wants to cache the chain of trust itself, more power to
David> it.
David> AFAIK, the way to get the cache to "do the right thing" is
David> CD=1.
I'm not convinced.
Let take an example:
example. secured
b.example. supposed to be secured, but expired SIG
c.b.example. secured
Given, QNAME=d.c.b.example.
one has a failure. How can the SASR even *GET* the SOA/DS/NS record for
c.b.example?
If CD=1 will force the security-aware-cachine-resolver to ignore that
it has already failed to get b.example. NS, then great. But, I haven't
experienced this kind of thing in the field.
>> o We need something like the CD-bit, that will return an entire
>> chain of trust, which consists of the RR's you specified above:
>> ALL keys, ALL DSs, ALL RRSIGs, and the RRset,
David> Why?
Because a) I want to audit it.
b) admins need to see it anyway.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQJ/054qHRg3pndX9AQEEZAQAj8rCX/kXWYgCBSdU0bgYZ7rlbQWKMxR7
7TM6+hC86EsF6cyhljFcIzYLH+Cujed7niUJ2T5QSN/OfZAh1eDjBFtFgl5kRejk
F8ksa/kKSbldua7GJ/iTq2LXCtVS618hEwjAQqVuRjP6h3CXpRPYK0a1UZnSx1zH
Ln0oeB4oJX0=
=G02Y
-----END PGP SIGNATURE-----