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
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:24 muks]:

 > > 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).[...]
 >
 > 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.

 It'd depend on how likely the difference would be noticed.  I guess
 it's quite minor (something that could be noticed in crafted test
 cases, etc), and, if so, I'd unify these changes into a single summary
 changelog entry and note the compatibility issue there (not listing
 each affected rdata types, but as a general note).

 But if you think the difference is substantial, I'm not opposed to
 providing a separate entry.  In that case please show proposed text.

 On the latest branch:
 - I made a few suggested editorial changes to documentation
 - may be a matter of taste, but I'd personally not bother to assert
   the condition here
 {{{#!cpp
         // token is now assured to be of type STRING.
         assert(token.getType() == MasterToken::STRING);

         token.getString(keydata_substr);
 }}}
   for two reasons: first, I personally think assert() can be too
   strong for checking condition beyond a class boundary.  Secondly,
   `MasterLexer` is generally designed and implemented to be safe
   against this type of mismatch: `getString` throws an exception if
   it's not of a string type.  leaving a comment on this is fine,
   though.  I'd leave it to you, but if you agree please note there are
   several of such asserts in the branch.

 Unless you want to discuss the changelog text I think the branch is
 ready for merge (if you remove the assert, I guess that's trivial and
 doesn't require another round of review).

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