Changes between Version 4 and Version 5 of Rfc5155DetailedRequirements


Ignore:
Timestamp:
Nov 16, 2011, 4:47:03 PM (6 years ago)
Author:
stephen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Rfc5155DetailedRequirements

    v4 v5  
    88* Any qualifications or notes.
    99
     10== General Requirements of the Authoritative Server ==
    1011The following set of requirements cover the general capabilities of the authoritative server:
    1112
     
    4041|| 7.2/3/b || All NSEC3 RRs returned in a response must have a flags field set to 0 or 1. || || ||
    4142
    42 
     43== Inclusion of NSEC3 Records in Responses from Authoritative Server ==
    4344The following requirements cover the possible responses that the server can return that include NSEC3 records.  The number of NSEC3 records returned depends on QNAME and type of response.  Up to two of these RRs are determined by the "closest encloser" proof described in [http://tools.ietf.org/html/rfc5155#section-7.2.1 section 7.2.1 of RFC 5155]. This is stated as a requirement and as a component of other responses where needed.
    4445
    4546||= Number =||= Requirement =||= Implemented =||= Notes =||
    46 |||||||| '''Negative Responses''' ||
    4747|| 7.2.1 || The server should be capable of creating NSEC3 RRs that prove the existent of the "closest encloser" (or "closest provable encloser"). || || ||
    4848|| 7.2.2 || If the QNAME does not exist, the server should return a "closest encloser proof" for the name and an NSEC3 RR for the (non-existent) wildcard RR at the closest encloser. || || ||
     
    5858|| 7.3 || If there are multiple NSEC3PARAM RRs present at the apex of the zone, there are multiple NSEC3 chains present.  The server must use one chain for its responses, but may use any criteria as to which chain to use. || || ||
    5959
     60== Requirements on the Resolver ==
    6061The following requirements cover the interpretation of NSEC3 records by the resolver.
    6162