Changeset 325

Show
Ignore:
Timestamp:
05/08/07 10:59:01
Author:
jakob
Message:

format

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

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

    r324 r325  
    2323 
    2424  <front> 
    25   <title abbrev="DLV Pointer RR">The DNSSEC Lookaside Validation Pointer (DLVPTR) Resource Record</title> 
     25  <title abbrev="DLV Pointer RR">The DNSSEC Lookaside Validation 
     26   Pointer (DLVPTR) Resource Record</title> 
    2627 
    2728  <author initials="R" surname="Arends" fullname="Roy Arends"> 
    …… 
    5354   </address> 
    5455  </author> 
    55  
     56   
    5657  <date day="8" month="May" year="2007"/> 
    5758 
    5859  <area>Internet</area> 
    5960  <workgroup>DNS Extenstions Working Group</workgroup> 
    60  
     61   
    6162  <keyword>DNS</keyword> 
    6263  <keyword>DNSSEC</keyword> 
    …… 
    6465  <abstract> 
    6566   <t> 
    66      This document defines the DNSSEC Lookaside Validation Pointer (DLVPTR) 
    67      Resource Record (RR), for publishing pointers to DNSSEC Lookaside 
    68      Validation (DLV) records publised outside of the DNS delegation chain. 
    69    </t> 
    70  </abstract> 
    71  
     67    This document defines the DNSSEC Lookaside Validation Pointer 
     68    (DLVPTR) Resource Record (RR), for publishing pointers to DNSSEC 
     69    Lookaside Validation (DLV) records publised outside of the DNS 
     70    delegation chain. 
     71   </t> 
     72  </abstract> 
     73   
    7274 </front> 
    7375 
    …… 
    7678  <section title="Introduction"> 
    7779    
    78    <t>A <xref target="RFC4033">validator</xref>, in absence of a trust anchor for either the zone, or higher up in the delegation hierarchy, can not do DNSSEC validation. 
    79    The DLV method<xref target="ISC-TN-2006-1"/><xref target="RFC4431"/><xref target="I-D.weiler-dnssec-dlv"/> 
    80    was meant to address that by allowing the validator to have a trust anchor outside of the delegation hierarcy. Though the DLV method works in principle, it introduces other issues, in that it does not scale properly nor gives the  
    81    validator any freedom to allow multiple trust anchors within the same part of the namespace. 
     80   <t>A <xref target="RFC4033">validator</xref>, in absence of a trust 
     81    anchor for either the zone, or higher up in the delegation 
     82    hierarchy, can not do DNSSEC validation.  The DLV method <xref 
     83    target="ISC-TN-2006-1"/><xref target="RFC4431"/><xref 
     84     target="I-D.weiler-dnssec-dlv"/> was meant to address that by 
     85    allowing the validator to have a trust anchor outside of the 
     86    delegation hierarcy. Though the DLV method works in principle, it 
     87    introduces other issues, in that it does not scale properly nor 
     88    gives the validator any freedom to allow multiple trust anchors 
     89    within the same part of the namespace. 
    8290   </t> 
    8391 
    …… 
    92100   
    93101  <section title="The rationale behind DLVPTR"> 
    94   <t> 
    95   <list> 
    96         <t>(1) DNSSEC absence of trust anchor</t> 
    97         <t>(2) Addressed by DLV method</t> 
    98         <t>(3) Problems with DLV method</t> 
    99         <t>(4) how we address those problems</t> 
    100   </list> 
    101   </t> 
    102   <t> 
    103    The scaling issues are somewhat addressed by DLV by introduction of Aggressive Negative Caching (ANC). Though ANC optimizes the load on the DLV registry, it does not give the validator nor the zone-operator any freedom to allow multiple trust anchors within the same part of the namespace. 
    104    </t> 
    105    <t>Aggressive Negative Caching is a method to optimize the load on the DLV registry. The resolver uses an obtained NSEC record to determine which future requests are futile. This is against the spirit of RFC 4035 (citation needed). 
     102   <t> 
     103    <list> 
     104     <t>(1) DNSSEC absence of trust anchor</t> 
     105     <t>(2) Addressed by DLV method</t> 
     106     <t>(3) Problems with DLV method</t> 
     107     <t>(4) how we address those problems</t> 
     108    </list> 
     109   </t> 
     110<!-- 
     111   <t> 
     112   The scaling issues are somewhat addressed by DLV by introduction of 
     113   Aggressive Negative Caching (ANC). Though ANC optimizes the load on 
     114   the DLV registry, it does not give the validator nor the 
     115   zone-operator any freedom to allow multiple trust anchors within 
     116   the same part of the namespace. 
     117   </t> 
     118   <t>Aggressive Negative Caching is a method to optimize the load on 
     119   the DLV registry. The resolver uses an obtained NSEC record to 
     120   determine which future requests are futile. This is against the 
     121   spirit of RFC 4035 (citation needed). 
    106122   </t> 
    107123   <t> 
    108124   A DLV registry might not 
    109125   </t> 
    110  
    111 <!-- 
    112    <t> 
    113     [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.] 
    114    </t> 
    115 --> 
    116  
    117    <t> 
    118     <xref target="RFC4431">RFC 4431</xref> specified the DLV DNS Resource Record, introducing the concept of trust anchors outside the delegation chain. This allows zone-administrators to have their DNSSEC 
    119     <xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/>  
    120     signed zone secured independent of the DNSSEC status of the parent. The DLV trust anchor needs to be configured in a validator in order to allow this non-hierarchial trust validation. Though DLV was intended to be a temporary trust-chain  
    121      
    122    </t> 
    123  
    124   </section> 
    125  
    126  
     126--> 
     127 
     128<!-- 
     129   <t> 
     130   [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.] 
     131   </t> 
     132--> 
     133 
     134<!-- 
     135   <t> 
     136    <xref target="RFC4431">RFC 4431</xref> specified the DLV DNS 
     137    Resource Record, introducing the concept of trust anchors outside 
     138    the delegation chain. This allows zone-administrators to have 
     139    their DNSSEC <xref target="RFC4033"/><xref target="RFC4034"/><xref 
     140    target="RFC4035"/> signed zone secured independent of the DNSSEC 
     141    status of the parent. The DLV trust anchor needs to be configured 
     142    in a validator in order to allow this non-hierarchial trust 
     143    validation. Though DLV was intended to be a temporary trust-chain ... 
     144   </t> 
     145--> 
     146 
     147  </section> 
     148   
    127149  <section title="DLVPTR Processing"> 
    128   <t> 
    129   <list> 
    130    <t>DLV-ANCHOR &amp;&amp; DLVPTR &amp;&amp; DLV == record</t> 
    131    <t>DLV-ANCHOR &amp;&amp; (!DLV) == remove</t> 
    132   </list> 
    133   </t> 
     150  <t> 
     151    <list> 
     152     <t>DLV-ANCHOR &amp;&amp; DLVPTR &amp;&amp; DLV == record</t> 
     153     <t>DLV-ANCHOR &amp;&amp; (!DLV) == remove</t> 
     154    </list> 
     155  </t> 
    134156  </section> 
    135157 
    …… 
    137159  <section title="The DLVPTR Resource Record"> 
    138160 
    139     <section title="The DLVPTR RDATA Format"> 
    140  
     161   <section title="The DLVPTR RDATA Format"> 
    141162    <t> 
    142163      The DLVPTR (type=TBD) record contains a domain name. 
    143164    </t> 
    144  
    145165    <figure> 
    146       <artwork> 
     166     <artwork> 
    147167      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
    148168      /                 DLVPTRDNAME                   / 
    149169      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
    150       </artwork> 
     170     </artwork> 
    151171    </figure> 
    152  
    153   <t> 
    154     DLVPTR records cause no additional section processing.  These RRs are 
    155     used in domains to point to some other location in the domain space. 
    156     These records are simple data, and don't imply any special processing 
    157     similar to that performed by CNAME, which identifies aliases. 
    158   </t> 
    159  
    160   </section> 
    161  
    162   <section title="Presentation Format of the DLVPTR RR"> 
    163172    <t> 
    164       The RDATA of the presentation format of the DLVPTR resource record 
    165       consists of one string (the domain name of the target 
    166       <xref target="RFC4431">DLV</xref>), e.g.: 
     173     DLVPTR records cause no additional section processing.  These RRs 
     174     are used in domains to point to some other location in the domain 
     175     space.  These records are simple data, and don't imply any 
     176     special processing similar to that performed by CNAME, which 
     177     identifies aliases. 
     178    </t> 
     179   </section> 
     180 
     181   <section title="Presentation Format of the DLVPTR RR"> 
     182    <t> 
     183     The RDATA of the presentation format of the DLVPTR resource 
     184     record consists of one string (the domain name of the target 
     185     <xref target="RFC4431">DLV</xref>), e.g.: 
    167186    </t> 
    168187    <figure> 
    …… 
    180199   <t> 
    181200<!-- 
    182    [explicitly explain the danger of the upgrade prevention attack, a specific part of the downgrade attack class] 
    183    [since we allow binding of a name with an arbitrary identifier in an arbitrary DLV registry, enumerating a DLV registry does not leak the DLV customer name. As an example, the DLVPTR can bind the zone 'example.' to identifier 'customer5.[registry_name]. Enumerating the registry would just reveal 'customer5', but not 'example.' Note that there is no restriction on the identifier. It can be a Base32 encoded hash value, or, if the registry chose to deploy NSEC3, the actual customer zone 'example.']     
     201    [explicitly explain the danger of the upgrade prevention attack, a 
     202    specific part of the downgrade attack class] 
     203 
     204    [since we allow binding of a name with an arbitrary identifier in 
     205    an arbitrary DLV registry, enumerating a DLV registry does not leak 
     206    the DLV customer name. As an example, the DLVPTR can bind the zone 
     207    'example.' to identifier 'customer5.[registry_name]. Enumerating the 
     208    registry would just reveal 'customer5', but not 'example.' Note that 
     209    there is no restriction on the identifier. It can be a Base32 encoded 
     210    hash value, or, if the registry chose to deploy NSEC3, the actual 
     211    customer zone 'example.'] 
    184212--> 
    185213   </t> 
    …… 
    193221   </t> 
    194222  </section> 
    195  
     223   
    196224 </middle> 
    197225 
    …… 
    199227 
    200228  <references title="Normative References"> 
    201        &RFC2119; 
    202        &RFC4431; 
     229   &RFC2119; 
     230   &RFC4431; 
    203231  </references> 
    204232 
    205233  <references title="Informative References"> 
    206        &RFC4033; 
    207        &RFC4034; 
    208        &RFC4035; 
    209  
    210     <reference anchor="ISC-TN-2006-1"> 
    211       <front> 
    212         <title>DNSSEC Lookaside Validation (DLV)</title> 
    213         <author initials='P' surname='Vixie' fullname='Paul Vixie'> 
    214           <organization>Internet Systems Consortium</organization> 
    215         </author> 
    216         <author initials='M' surname='Andrews' fullname='Mark Andrews'> 
    217           <organization>Internet Systems Consortium</organization> 
    218         </author> 
    219         <date month='April' day='16' year='2006' /> 
    220       </front> 
    221       <seriesInfo name='ISC-TN' value='2006-1' /> 
    222       <format type='HTML' 
    223         target='http://www.isc.org/pubs/tn/isc-tn-2006-1.html' /> 
    224       <format type='TXT' 
    225         target='http://www.isc.org/pubs/tn/isc-tn-2006-1.txt' /> 
    226     </reference> 
    227  
    228        &DLV; 
    229  
     234   &RFC4033; 
     235   &RFC4034; 
     236   &RFC4035; 
     237 
     238   <reference anchor="ISC-TN-2006-1"> 
     239    <front> 
     240     <title>DNSSEC Lookaside Validation (DLV)</title> 
     241     <author initials='P' surname='Vixie' fullname='Paul Vixie'> 
     242      <organization>Internet Systems Consortium</organization> 
     243     </author> 
     244     <author initials='M' surname='Andrews' fullname='Mark Andrews'> 
     245      <organization>Internet Systems Consortium</organization> 
     246     </author> 
     247     <date month='April' day='16' year='2006' /> 
     248    </front> 
     249    <seriesInfo name='ISC-TN' value='2006-1' /> 
     250    <format type='HTML' 
     251     target='http://www.isc.org/pubs/tn/isc-tn-2006-1.html' /> 
     252    <format type='TXT' 
     253     target='http://www.isc.org/pubs/tn/isc-tn-2006-1.txt' /> 
     254   </reference> 
     255    
     256   &DLV; 
     257    
    230258  </references> 
    231259