Changeset 327

Show
Ignore:
Timestamp:
05/09/07 16:25:43
Author:
roy
Message:

cleaned up, and starting with DLVPTR processing

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • aob/draft-arends-dnsext-dlvptr-xx.xml

    r326 r327  
    7979   <t>DNSSEC Lookaside Validation (DLV) <xref target="ISC-TN-2006-1"/> 
    8080   <xref target="RFC4431"/><xref target="I-D.weiler-dnssec-dlv"/> is a  
    81    method to publish Trust Anchors (TAs) for islands of security in a  
    82    repository independent of the island of security. This, in turn, has  
    83    the potential for efficient TA management on the validator, as the  
    84    validator can configure the TA for the DLV repository, instead of  
     81   method to publish Trust Anchors (TAs) for islands of security  
     82   <xref target="RFC4033"/> outside the delegation chain. This, in turn,  
     83   has the potential for efficient TA management on the validator, as  
     84   the validator can configure the TA for the DLV repository, instead of  
    8585   TAs for each island of security.  
    8686   </t> 
    …… 
    9898   </t> 
    9999   <t> 
     100   This change allows configuration of multiple DLV TAs in a  
     101   validator without significantly degrading response times. 
     102   </t> 
     103   <t> 
    100104    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
    101105    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
    …… 
    106110  </section> 
    107111   
    108   <section title="The rationale behind DLVPTR"> 
    109    <t> 
    110     <list> 
    111      <t>(1) DNSSEC absence of trust anchor</t> 
    112      <t>(2) Addressed by DLV method</t> 
    113      <t>(3) Problems with DLV method</t> 
    114      <t>(4) how we address those problems</t> 
    115     </list> 
    116    </t> 
    117 <!-- 
     112  <!-- 
    118113   <t> 
    119114   The scaling issues are somewhat addressed by DLV by introduction of 
    …… 
    133128--> 
    134129 
    135 <!-- 
    136    <t> 
    137    [we should get two points accross. (1) zone admins have a choice in registry to use, val-admins have a choice in registry to trust. (2) all the scaling cruft.] 
    138    </t> 
    139 --> 
    140  
    141 <!-- 
    142    <t> 
    143     <xref target="RFC4431">RFC 4431</xref> specified the DLV DNS 
    144     Resource Record, introducing the concept of trust anchors outside 
    145     the delegation chain. This allows zone-administrators to have 
    146     their DNSSEC <xref target="RFC4033"/><xref target="RFC4034"/><xref 
    147     target="RFC4035"/> signed zone secured independent of the DNSSEC 
    148     status of the parent. The DLV trust anchor needs to be configured 
    149     in a validator in order to allow this non-hierarchial trust 
    150     validation. Though DLV was intended to be a temporary trust-chain ... 
    151    </t> 
    152 --> 
    153  
    154130  </section> 
    155131   
    156132  <section title="DLVPTR Processing"> 
    157133   <t> 
    158     <list> 
     134   A Security Aware Resolver sends requests with the DNSSEC-OK bit set,  
     135   regardless of any configured TA. It expects the zone at a configured  
     136   TA to be secured, and thus responses to contain DNSSEC records. 
     137   </t> 
     138   <t> 
     139   When a Security Aware Resolver has no TAs configured for a requested  
     140   name, and has one or more DLV-TAs configured, and receives a response for that name 
     141   containing DNSSEC records, it sends a request for a DLVPTR to the highest point in the 
     142   delegation chain that contained DNSSEC records. 
     143   </t> 
     144   <t> 
     145       <list> 
    159146     <t>DLV-ANCHOR &amp;&amp; DLVPTR &amp;&amp; DLV == record</t> 
    160147     <t>DLV-ANCHOR &amp;&amp; (!DLV) == remove</t> 
    …… 
    178165    </figure> 
    179166    <t> 
    180      DLVPTR records cause no additional section processing.  These RRs 
     167     A DLVPTR record causes no additional section processing. DLVPTR RRs 
    181168     are used in domains to point to some other location in the domain 
    182      space.  These records are simple data, and don't imply any 
    183      special processing similar to that performed by CNAME, which 
    184      identifies aliases. 
     169     space. 
    185170    </t> 
    186171   </section>