BIND 10 #2295: clarify the semantics of datasrc/memory/ZoneData::isSigned()

BIND 10 Development do-not-reply at isc.org
Thu Sep 27 00:31:41 UTC 2012


#2295: clarify the semantics of datasrc/memory/ZoneData::isSigned()
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  data source   |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 Currently, different parts of the in-memory data source related
 classes use different semantics:

 - the zone loader (memory_client.cc) set it to true when it adds
   NSEC/NSEC3 or NSEC3PARAM RRs to the zone
 - the zone finder implementation considers the zone is "NSEC3 signed"
   regardless of the value of "is signed" flag (so the zone loader
   behavior for NSEC3/NSECPARAM is meaningless)
 - in the zone data documentation, it's (intentionally) left open, but
   hinted as if it means the zone has a DNSKEY RR (at the origin).

 The difference is not an immediate issue, but when we support
 incremental zone signing or migration between NSEC and NSEC3, there
 can be an intermediate state where the zone should rather be
 considered "unsigned" even if it contains some NSEC or NSEC3 RRs.
 And then the difference and the current assumption may cause real
 troubles.

 So my suggestion is to adopt the hint policy in the zone data
 documentation: set the "signed" flag of zone to true iff the has a
 DNSKEY RR at the origin (and make sure this condition is preserved
 when we add incremental zone updates).  The zone finder implementation
 should check both "signed" and `isNSEC3Signed()` conditions to set the
 "NSEC3 signed" flag.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2295>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list