Re: [dnsext] Design team report on dnssec-bis-updates and CD bit

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I sort of agree with Michael and George, that there are multiple
options, this seems to be a list of what local-policy a resolver could
implement.  What a CD flag does works fine: the upstream either gives
the unaltered, unabridged data or does "funky policy" on it.  Below I
attempt to list some pros and cons.

* After root key deployment, it is likely that if a trust anchor is in
place, it is the root key.  Thus everything falls under the trust
anchor.  And the tables are not useful in that case.
* CD=1 in general makes debugging DNSSEC easier.  This for the question
'help or hinder DNSSEC deployment'.
* intelligence at the end points.  CD=1 makes sure that the end point is
doin' the do, and I think we ought to promote that principle.
* Seems that the current implementations all set CD=1, but I could be
mistaken.
* If you want to improve current implementations, 'CD=1 cache MAY be
validated in order to attempt to not cache nonvalidatable data', so
using its trust anchors simply to attempt to flush bogus data out of the
cache (but not refusing to serve contents).
* The only case I can think of that has 'cooperating validators with
different trust anchors' in today's dnssec deployment is a firm that has
a local DNS zone signed, and also uses an upstream ISP cache.  But it
would be trivial to add the public internet trust anchor to the firm's
validators?

Therefore I think the always-set is simpler.  I think these tables are
not appropriate in dnssec-bis-updates.

Best regards,
   Wouter

On 07/12/2010 06:59 AM, Michael Graff wrote:
> On 7/9/10 9:21 AM, Andrew Su
>> Please offer your thoughts on these models and state which of them you
>> think should be in the draft as the way to handle the CD bit.  We will
>> devote some time in the Monday Maastricht session to this issue.  We
>> want to bring it to a close at that meeting.
> 
> I may make some sense to list the behaviors of the common resolvers, and
> define what problems we're trying to fix by selectively setting the CD=1
> flag.  There was mention that there was lack of agreement, but no
> reasons (pros, cons) for the various choices really.
> 
> Please also note that you might not know that you have a covering TA for
> the name in question in all cases, specifically DLV or when learning
> about the existence of DNSSEC does not start from the parent and move
> into the child, but moves the other way.  Which some resolvers implement.
> 
> Also, just because a query did not have CD set, it does not mean the
> next one won't, and I believe it's against the RFCs to query for RRSIG
> or NXT records.  This would mean more queries, and to be safe, probably
> two caches in the resolver, one for CD=1 and one for CD=0.
> 
> 
> --Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkw66tEACgkQkDLqNwOhpPjU2ACgpIqrfC0isYDpifB129MNak/7
rQkAn1opEjylLQhzK+ofL1E3F6lOq7cx
=jhgI
-----END PGP SIGNATURE-----