BIND 10 #2387: support generic version of rdata::createRdata(text) in DNSKEY, NSEC3, NSEC3PARAM

[BIND 10 Development]

#2387: support generic version of rdata::createRdata(text) in DNSKEY, NSEC3,
NSEC3PARAM
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => jinmei


Comment:

 Hi Jinmei

 Replying to [comment:22 jinmei]:
 > '''changelog'''
 >
 > My understanding is that we are now skipping explicit changelogs for
 > each rdata subtask (and we'll probably create one unified entry once
 > all these tasks are completed).  But I noticed #2386 and #2391 had
 > a changelog entry; I don't know whether there was a specific reason
 > for it (because it was Paul's debut?).  If my general understanding is
 > correct, the best in terms of consistency would be to remove the
 > changelog entry for #2386 and #2391, and not add an entry for this
 > ticket.  but this is probably too minor and no one would notice/care.
 > so I'm okay with any resolution; however, in general, if we add to a
 > changelog, the text should generally be reviewed, too (to avoid
 > creating an unhelpful or non-understandable entry).

 I guess the `ChangeLog` entries for #2386 and #2391 were added as they
 went in another public release tarball of BIND 10.

 The reason why I asked about the `ChangeLog` entry was not due to the
 topic of this bug itself, but due to other changes that have gone in
 towards RDATA validation. Some RDATA that may have been accepted as
 valid before is rejected now, and vice versa.

 > '''nsec3_50.cc'''
 >
 > hmm, I overlooked the possibility of the leak, too.  I think we need
 > to make an explicit comment about why we need auto_ptr.  Also, we
 > should need to include `<memory>` for `std::auto_ptr`.  All apply to
 > other similar fixes, too.

 Added now.

 > '''dnskey_48.cc'''
 >
 > - I'd revise doxygen comment to clarify the public key field can be
 >   missing.

 Done.

 > - An exact copy of this comment repeats.  I'd have one refer to
 >   another for DRY:
 > {{{#!cpp
 >     // If key data is missing, it's OK. BIND 9 seems to accept such
 >     // cases. What we should do could be debatable, but since this field
 >     // is algorithm dependent and our implementation doesn't reject
 >     // unknown algorithms, we are lenient here.
 > }}}
 >   (note also the previous point.  maybe we can simply refer to the
 >   doxygen)

 It refers to the API doc now.

 > '''xxx_fromWire.spec'''
 >
 > You should be able to omit parameters if they are the default:
 > {{{
 > flags: 257
 > protocol: 3
 > algorithm: 5
 > }}}

 Done. :)

-- 
Ticket URL: <https://bind10.isc.org/ticket/2387#comment:24>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development