Trait trust_dns::client::Client [] [src]

pub trait Client<C: ClientHandle> {
    fn get_io_loop(&self) -> RefMut<Core>;
fn get_client_handle(&self) -> RefMut<C>; fn query(
        &self,
        name: &Name,
        query_class: DNSClass,
        query_type: RecordType
    ) -> ClientResult<Message> { ... }
fn notify<R>(
        &mut self,
        name: Name,
        query_class: DNSClass,
        query_type: RecordType,
        rrset: Option<R>
    ) -> ClientResult<Message>
    where
        R: IntoRecordSet
, { ... }
fn create<R>(&self, rrset: R, zone_origin: Name) -> ClientResult<Message>
    where
        R: IntoRecordSet
, { ... }
fn append<R>(
        &self,
        rrset: R,
        zone_origin: Name,
        must_exist: bool
    ) -> ClientResult<Message>
    where
        R: IntoRecordSet
, { ... }
fn compare_and_swap<CR, NR>(
        &self,
        current: CR,
        new: NR,
        zone_origin: Name
    ) -> ClientResult<Message>
    where
        CR: IntoRecordSet,
        NR: IntoRecordSet
, { ... }
fn delete_by_rdata<R>(
        &self,
        record: R,
        zone_origin: Name
    ) -> ClientResult<Message>
    where
        R: IntoRecordSet
, { ... }
fn delete_rrset(
        &self,
        record: Record,
        zone_origin: Name
    ) -> ClientResult<Message> { ... }
fn delete_all(
        &self,
        name_of_records: Name,
        zone_origin: Name,
        dns_class: DNSClass
    ) -> ClientResult<Message> { ... } }

Client trait which implements basic DNS Client operations.

As of 0.10.0, the Client is now a wrapper around the ClientFuture, which is a futures-rs and tokio-rs based implementation. This trait implements syncronous functions for ease of use.

There was a strong attempt to make it backwards compatible, but making it a drop in replacement for the old Client was not possible. This trait has two implentations, the SyncClient which is a standard DNS Client, and the SecureSyncClient which is a wrapper on SecureClientHandle providing DNSSec validation.

note When upgrading from previous usage, both SyncClient and SecureSyncClient have an signer which can be optionally associated to the Client. This replaces the previous per-function parameter, and it will sign all update requests (this matches the ClientFuture API).

Required Methods

get a mutable reference to the tokio Core associated to the Client

Get a mutable handle reference tot the Core assiated to the Client

Provided Methods

A classic DNS query, i.e. does not perform and DNSSec operations

Note As of now, this will not recurse on PTR or CNAME record responses, that is up to the caller.

Arguments

  • name - the label to lookup
  • query_class - most likely this should always be DNSClass::IN
  • query_type - record type to lookup

Sends a NOTIFY message to the remote system

Arguments

  • name - the label which is being notified
  • query_class - most likely this should always be DNSClass::IN
  • query_type - record type which has been updated
  • rrset - the new version of the record(s) being notified

Sends a record to create on the server, this will fail if the record exists (atomicity depends on the server)

RFC 2136, DNS Update, April 1997

 2.4.3 - RRset Does Not Exist

  No RRs with a specified NAME and TYPE (in the zone and class denoted
  by the Zone Section) can exist.

  For this prerequisite, a requestor adds to the section a single RR
  whose NAME and TYPE are equal to that of the RRset whose nonexistence
  is required.  The RDLENGTH of this record is zero (0), and RDATA
  field is therefore empty.  CLASS must be specified as NONE in order
  to distinguish this condition from a valid RR whose RDLENGTH is
  naturally zero (0) (for example, the NULL RR).  TTL must be specified
  as zero (0).

2.5.1 - Add To An RRset

   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
   and RDATA are those being added, and CLASS is the same as the zone
   class.  Any duplicate RRs will be silently ignored by the primary
   master.

Arguments

  • rrset - the record(s) to create
  • zone_origin - the zone name to update, i.e. SOA name

The update must go to a zone authority (i.e. the server used in the ClientConnection)

Appends a record to an existing rrset, optionally require the rrset to exis (atomicity depends on the server)

RFC 2136, DNS Update, April 1997

2.4.1 - RRset Exists (Value Independent)

  At least one RR with a specified NAME and TYPE (in the zone and class
  specified in the Zone Section) must exist.

  For this prerequisite, a requestor adds to the section a single RR
  whose NAME and TYPE are equal to that of the zone RRset whose
  existence is required.  RDLENGTH is zero and RDATA is therefore
  empty.  CLASS must be specified as ANY to differentiate this
  condition from that of an actual RR whose RDLENGTH is naturally zero
  (0) (e.g., NULL).  TTL is specified as zero (0).

2.5.1 - Add To An RRset

   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
   and RDATA are those being added, and CLASS is the same as the zone
   class.  Any duplicate RRs will be silently ignored by the primary
   master.

Arguments

  • rrset - the record(s) to append to an RRSet
  • zone_origin - the zone name to update, i.e. SOA name
  • must_exist - if true, the request will fail if the record does not exist

The update must go to a zone authority (i.e. the server used in the ClientConnection). If the rrset does not exist and must_exist is false, then the RRSet will be created.

Compares and if it matches, swaps it for the new value (atomicity depends on the server)

 2.4.2 - RRset Exists (Value Dependent)

  A set of RRs with a specified NAME and TYPE exists and has the same
  members with the same RDATAs as the RRset specified here in this
  section.  While RRset ordering is undefined and therefore not
  significant to this comparison, the sets be identical in their
  extent.

  For this prerequisite, a requestor adds to the section an entire
  RRset whose preexistence is required.  NAME and TYPE are that of the
  RRset being denoted.  CLASS is that of the zone.  TTL must be
  specified as zero (0) and is ignored when comparing RRsets for
  identity.

 2.5.4 - Delete An RR From An RRset

  RRs to be deleted are added to the Update Section.  The NAME, TYPE,
  RDLENGTH and RDATA must match the RR being deleted.  TTL must be
  specified as zero (0) and will otherwise be ignored by the primary
  master.  CLASS must be specified as NONE to distinguish this from an
  RR addition.  If no such RRs exist, then this Update RR will be
  silently ignored by the primary master.

 2.5.1 - Add To An RRset

  RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
  and RDATA are those being added, and CLASS is the same as the zone
  class.  Any duplicate RRs will be silently ignored by the primary
  master.

Arguements

  • current - the current rrset which must exist for the swap to complete
  • new - the new rrset with which to replace the current rrset
  • zone_origin - the zone name to update, i.e. SOA name

The update must go to a zone authority (i.e. the server used in the ClientConnection).

Deletes a record (by rdata) from an rrset, optionally require the rrset to exist.

RFC 2136, DNS Update, April 1997

2.4.1 - RRset Exists (Value Independent)

  At least one RR with a specified NAME and TYPE (in the zone and class
  specified in the Zone Section) must exist.

  For this prerequisite, a requestor adds to the section a single RR
  whose NAME and TYPE are equal to that of the zone RRset whose
  existence is required.  RDLENGTH is zero and RDATA is therefore
  empty.  CLASS must be specified as ANY to differentiate this
  condition from that of an actual RR whose RDLENGTH is naturally zero
  (0) (e.g., NULL).  TTL is specified as zero (0).

2.5.4 - Delete An RR From An RRset

  RRs to be deleted are added to the Update Section.  The NAME, TYPE,
  RDLENGTH and RDATA must match the RR being deleted.  TTL must be
  specified as zero (0) and will otherwise be ignored by the primary
  master.  CLASS must be specified as NONE to distinguish this from an
  RR addition.  If no such RRs exist, then this Update RR will be
  silently ignored by the primary master.

Arguments

  • rrset - the record(s) to delete from a RRSet, the name, type and rdata must match the record to delete
  • zone_origin - the zone name to update, i.e. SOA name

The update must go to a zone authority (i.e. the server used in the ClientConnection). If the rrset does not exist and must_exist is false, then the RRSet will be deleted.

Deletes an entire rrset, optionally require the rrset to exist.

RFC 2136, DNS Update, April 1997

2.4.1 - RRset Exists (Value Independent)

  At least one RR with a specified NAME and TYPE (in the zone and class
  specified in the Zone Section) must exist.

  For this prerequisite, a requestor adds to the section a single RR
  whose NAME and TYPE are equal to that of the zone RRset whose
  existence is required.  RDLENGTH is zero and RDATA is therefore
  empty.  CLASS must be specified as ANY to differentiate this
  condition from that of an actual RR whose RDLENGTH is naturally zero
  (0) (e.g., NULL).  TTL is specified as zero (0).

2.5.2 - Delete An RRset

  One RR is added to the Update Section whose NAME and TYPE are those
  of the RRset to be deleted.  TTL must be specified as zero (0) and is
  otherwise not used by the primary master.  CLASS must be specified as
  ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
  If no such RRset exists, then this Update RR will be silently ignored
  by the primary master.

Arguments

  • record - the record to delete from a RRSet, the name, and type must match the record set to delete
  • zone_origin - the zone name to update, i.e. SOA name

The update must go to a zone authority (i.e. the server used in the ClientConnection). If the rrset does not exist and must_exist is false, then the RRSet will be deleted.

Deletes all records at the specified name

RFC 2136, DNS Update, April 1997

2.5.3 - Delete All RRsets From A Name

  One RR is added to the Update Section whose NAME is that of the name
  to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
  be specified as zero (0) and is otherwise not used by the primary
  master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
  and RDATA must therefore be empty.  If no such RRsets exist, then
  this Update RR will be silently ignored by the primary master.

Arguments

  • name_of_records - the name of all the record sets to delete
  • zone_origin - the zone name to update, i.e. SOA name
  • dns_class - the class of the SOA

The update must go to a zone authority (i.e. the server used in the ClientConnection). This operation attempts to delete all resource record sets the the specified name reguardless of the record type.

Implementors