view release on metacpan or  search on metacpan

lib/DNS/LDNS.pm  view on Meta::CPAN

=item B<DNS::LDNS::RBTree>

Represents a tree of DNSSecName nodes (maps to the ldns_rbtree struct)

=item B<DNS::LDNS::RBNode>

Represents a node in the RBTree (maps to the ldns_rbnode struct)

=item B<DNS::LDNS::DNSSecName>

Represents a dname in a DNSSecZone and holds a DNSSecRRSets list for
this  dname, possibly with signatures (maps to the ldns_dnssec_name
struct)

=item B<DNS::LDNS::DNSSecRRSets>

Represents a linked list of DNSSec RR sets, possibly with signatures
(maps  to the ldns_dnssec_rrsets struct)

=item B<DNS::LDNS::DNSSecRRs>

Represents a linked list of RRs (maps to the ldns_dnssec_rrs struct)

=item B<DNS::LDNS::DNSSecDataChain>

Represents a chain of RR, DNSKEY, and DS data used for building a
dnssec  trust tree (maps to the ldns_dnssec_data_chain struct)

=item B<DNS::LDNS::DNSSecTrustTree>

Represents a tree of chained trust relationships from a signed RR to a
set  of trust anchors (maps to the ldns_dnssec_trust_tree struct).

=item B<DNS::LDNS::GC>

Garbage collector. Handles ownership dependencies and freeing data
used by  the other classes. Used internally only.

=back

One thing to note is that some of the classes have a seemingly
overlapping  functionality. The Zone and RRList are used to represent
a generic zone. It  may contain dnssec data but treats it like any
other dns data and does not  have any knowledge of its structure. The
DNSSec* and RB* classes are  building blocks for representing a signed
zone in a more structured way.

=head2 Static functions

  str = rr_type2str(type)
  str = rr_class2str(class)
  type = rr_type_by_name(str)
  class = rr_class_by_name(str)
  str = pkt_opcode2str(opcode)
  str = pkt_rcode2str(rcode)
  error = errorstr_by_id(status)
  str = DNS::LDNS::last_error
  status = DNS::LDNS::last_status
  rr = dnssec_create_nsec(from, to, type)
  rr = dnssec_create_nsec3(from, to, algorithm, flags, iterations, salt)
  rr = create_nsec(current, next, rrs)
  rr = create_nsec3(cur_owner, cur_zone, algorithm, flags,
                    iterations, salt, empty_nonterminals)
  algo = signing_algorithm_by_name(name)
  bool = key_algorithm_supported(algorithm)
  rr = read_anchor_file(filename)

=head2 Object references and cloning

Since some of the objects are found as sub objects within other
objects, it  is important to know how the wrapper classes handle
object references,  dependencies and cloning. The general rule is that
accessor methods just  return a reference to the object while methods
inserting data inserts inserts  a clone of the object. Most classes
have a clone method which can be used if  a cloned object is what you
really want.

=head3 Examples

DNS::LDNS::Zone::rrs returns a reference to the DNS::LDNS::RRList
within  the zone, so if you make changes to the RRList you also
changes the Zone  object.

DNS::LDNS::RRList::push(rr) clones the rr, then pushes the cloned rr
to the  list. Changing the rr afterwards will not change the list.

An exception is the Key class which does not have a clone
mechanism. In this  case we allow a free Key to be added to only one
KeyList. Adding it to  multiple lists will provoke an error.

The wrapper keeps track of allocated data structures and references.
Whenever data is no longer referred to by a perl object, it will be
freed.

=head2 ERROR HANDLING

The purpose for writing this wrapper class has been to be able to
process zone file data with good time performance. Data checking and
error handling is a bit sparse.

Most constructors will update the DNS::LDNS::last_status variable if
they fail (return undef). Wrapper methods to ldns functions which would
return a status will update the static DNS::LDNS::last_status variable.
Most methods do not return a status and will not reset this variable
even though they succeeds.

=head2 EXPORT

None by default.

=head1 BUGS

There no known bugs, although parts of the code has not yet been very
well tested. Bugreports will be greatly appreciated.

=head1 SEE ALSO

http://www.nlnetlabs.nl/projects/ldns

=head1 AUTHOR

Erik Pihl Ostlyngen, E<lt>erik.ostlyngen@norid.noE<gt>