DNS Extensions (dnsext)

The IESG | 17 May 2012 23:01

Last Call: <draft-ietf-dnsext-dnssec-bis-updates-18.txt> (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Clarifications and Implementation Notes for DNSSECbis'
  <draft-ietf-dnsext-dnssec-bis-updates-18.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document is a collection of technical clarifications to the
   DNSSECbis document set.  It is meant to serve as a resource to
   implementors as well as a repository of DNSSECbis errata.

   This document updates the core DNSSECbis documents (RFC4033, RFC4034,
   and RFC4035) as well as the NSEC3 specification (RFC5155).  It also
   defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ballot/

No IPR declarations have been submitted directly on this I-D.

(Continue reading)

headers

Mark Andrews | 21 May 2012 01:00

Re: Last Call: <draft-ietf-dnsext-dnssec-bis-updates-18.txt> (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard


I am repeating what I have said earlier during WGLS that Section
5.9., Always set the CD bit on Queries, contains bad advice on how
to set the CD bit.

The setting of CD make little difference if all the machines involved
are being correctly managed.  In that case all responses will
successfully validate.   However if there is a off path attacker
or one or more of the authorititive sources is returning stale
records the setting of CD is critical to ensuring that the ultimate
client can get the necessary records to ensure that the responses
it gets validate.

When there is a non-validating stub resolver all queries from that
client come in with CD=0 and a validating recursive server try
multiple authoritative servers until it gets a answer which validates
as secure or insecure, in other words it rejects answers from
attackers or from authoritative servers that return stale data.

Now take a validating validating stub resolver, if all queries from
that client come in the CD=1, them the recursive server returns the
answer from upstream immediately without filtering out bad responses.
If there is a off path attacker or if there is a stale authoritative
server then there is no way to ensure that the stub client will
ever get a answer that will validate.  It can continue to re-query
forever but there is no requirement for the recursive server to try
a different authoritative source or to wait for a valid response
from a authoritive source.

A similar problem arises when a recursive server is talking through

(Continue reading)