4.5.4.2.1. DSFRecords

class dyn.tm.services.dsf.DSFARecord(address, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An ARecord object which is able to store additional data for use by a TrafficDirector service.

__init__(address, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFARecord object

Parameters:
  • address – IPv4 address for the record
  • ttl – TTL for this record
  • label – A unique label for this DSFARecord
  • weight – Weight for this DSFARecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFAAAARecord(address, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An AAAARecord object which is able to store additional data for use by a TrafficDirector service.

__init__(address, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFAAAARecord object

Parameters:
  • address – IPv6 address for the record
  • ttl – TTL for this record
  • label – A unique label for this DSFAAAARecord
  • weight – Weight for this DSFAAAARecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFALIASRecord(alias, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An AliasRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(alias, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFALIASRecord object

Parameters:
  • alias – alias target name
  • ttl – TTL for this record
  • label – A unique label for this DSFALIASRecord
  • weight – Weight for this DSFALIASRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFCERTRecord(format, tag, algorithm, certificate, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An CERTRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(format, tag, algorithm, certificate, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFCERTRecord object

Parameters:
  • format – Numeric value for the certificate type
  • tag – Numeric value for the public key certificate
  • algorithm – Public key algorithm number used to generate the certificate
  • certificate – The public key certificate
  • ttl – TTL for this record
  • label – A unique label for this DSFCERTRecord
  • weight – Weight for this DSFCERTRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFCNAMERecord(cname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An CNAMERecord object which is able to store additional data for use by a TrafficDirector service.

__init__(cname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFCNAMERecord object

Parameters:
  • cname – Hostname
  • ttl – TTL for this record
  • label – A unique label for this DSFCNAMERecord
  • weight – Weight for this DSFCNAMERecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFDHCIDRecord(digest, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An DHCIDRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(digest, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFDHCIDRecord object

Parameters:
  • digest – Base-64 encoded digest of DHCP data
  • ttl – TTL for this record
  • label – A unique label for this DSFDHCIDRecord
  • weight – Weight for this DSFDHCIDRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFDNAMERecord(dname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An DNAMERecord object which is able to store additional data for use by a TrafficDirector service.

__init__(dname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFDNAMERecord object

Parameters:
  • dname – Target Hostname
  • ttl – TTL for this record
  • label – A unique label for this DSFDNAMERecord
  • weight – Weight for this DSFDNAMERecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFDNSKEYRecord(protocol, public_key, algorithm=5, flags=256, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An DNSKEYRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(protocol, public_key, algorithm=5, flags=256, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFDNSKEYRecord object

Parameters:
  • protocol – Numeric value for protocol
  • public_key – The public key for the DNSSEC signed zone
  • algorithm – Numeric value representing the public key encryption algorithm which will sign the zone. Must be one of 1 (RSA-MD5), 2 (Diffie-Hellman), 3 (DSA/SHA-1), 4 (Elliptic Curve), or 5 (RSA-SHA-1)
  • flags – Numeric value confirming this is the zone’s DNSKEY
  • ttl – TTL for this record
  • label – A unique label for this DSFDNSKEYRecord
  • weight – Weight for this DSFDNSKEYRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFDSRecord(digest, keytag, algorithm=5, digtype=1, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An DSRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(digest, keytag, algorithm=5, digtype=1, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFDSRecord object

Parameters:
  • digest – The digest in hexadecimal form. 20-byte, hexadecimal-encoded, one-way hash of the DNSKEY record surrounded by parenthesis characters ‘(‘ & ‘)’
  • keytag – The digest mechanism to use to verify the digest
  • algorithm – Numeric value representing the public key encryption algorithm which will sign the zone. Must be one of 1 (RSA-MD5), 2 (Diffie-Hellman), 3 (DSA/SHA-1), 4 (Elliptic Curve), or 5 (RSA-SHA-1)
  • digtype – the digest mechanism to use to verify the digest. Valid values are SHA1, SHA256
  • ttl – TTL for this record
  • label – A unique label for this DSFDSRecord
  • weight – Weight for this DSFDSRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFKEYRecord(algorithm, flags, protocol, public_key, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An KEYRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(algorithm, flags, protocol, public_key, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFKEYRecord object

Parameters:
  • algorithm – Numeric value representing the public key encryption algorithm which will sign the zone. Must be one of 1 (RSA-MD5), 2 (Diffie-Hellman), 3 (DSA/SHA-1), 4 (Elliptic Curve), or 5 (RSA-SHA-1)
  • flags – See RFC 2535 for information on KEY record flags
  • protocol – Numeric identifier of the protocol for this KEY record
  • public_key – The public key for this record
  • ttl – TTL for this record
  • label – A unique label for this DSFKEYRecord
  • weight – Weight for this DSFKEYRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFKXRecord(exchange, preference, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An KXRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(exchange, preference, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFKXRecord object

Parameters:
  • exchange – Hostname that will act as the Key Exchanger. The hostname must have a CNAMERecord, an ARecord and/or an AAAARecord associated with it
  • preference – Numeric value for priority usage. Lower value takes precedence over higher value where two records of the same type exist on the zone/node
  • ttl – TTL for this record
  • label – A unique label for this DSFKXRecord
  • weight – Weight for this DSFKXRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFLOCRecord(altitude, latitude, longitude, horiz_pre=10000, size=1, vert_pre=10, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An LOCRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(altitude, latitude, longitude, horiz_pre=10000, size=1, vert_pre=10, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFLOCRecord object

Parameters:
  • altitude – Measured in meters above sea level
  • horiz_pre
  • latitude – Measured in degrees, minutes, and seconds with N/S indicator for North and South
  • longitude – Measured in degrees, minutes, and seconds with E/W indicator for East and West
  • size
  • version
  • vert_pre
  • ttl – TTL for this record
  • label – A unique label for this DSFLOCRecord
  • weight – Weight for this DSFLOCRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFIPSECKEYRecord(precedence, gatetype, algorithm, gateway, public_key, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An IPSECKEYRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(precedence, gatetype, algorithm, gateway, public_key, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFIPSECKEYRecord object

Parameters:
  • precedence – Indicates priority among multiple IPSECKEYS. Lower numbers are higher priority
  • gatetype – Gateway type. Must be one of 0, 1, 2, or 3
  • algorithm – Public key’s cryptographic algorithm and format. Must be one of 0, 1, or 2
  • gateway – Gateway used to create IPsec tunnel. Based on Gateway type
  • public_key – Base64 encoding of the public key. Whitespace is allowed
  • ttl – TTL for this record
  • label – A unique label for this DSFIPSECKEYRecord
  • weight – Weight for this DSFIPSECKEYRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFMXRecord(exchange, preference=10, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An MXRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(exchange, preference=10, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFMXRecord object

Parameters:
  • exchange – Hostname of the server responsible for accepting mail messages in the zone
  • preference – Numeric value for priority usage. Lower value takes precedence over higher value where two records of the same type exist on the zone/node.
  • ttl – TTL for this record
  • label – A unique label for this DSFMXRecord
  • weight – Weight for this DSFMXRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFNAPTRRecord(order, preference, services, regexp, replacement, flags='U', ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An NAPTRRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(order, preference, services, regexp, replacement, flags='U', ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFNAPTRRecord object

Parameters:
  • order – Indicates the required priority for processing NAPTR records. Lowest value is used first.
  • preference – Indicates priority where two or more NAPTR records have identical order values. Lowest value is used first.
  • services – Always starts with “e2u+” (E.164 to URI). After the e2u+ there is a string that defines the type and optionally the subtype of the URI where this NAPTRRecord points.
  • regexp – The NAPTR record accepts regular expressions
  • replacement – The next domain name to find. Only applies if this NAPTRRecord is non-terminal.
  • flags – Should be the letter “U”. This indicates that this NAPTR record terminal
  • ttl – TTL for this record
  • label – A unique label for this DSFNAPTRRecord
  • weight – Weight for this DSFNAPTRRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFPTRRecord(ptrdname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An PTRRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(ptrdname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFPTRRecord object

Parameters:
  • ptrdname – The hostname where the IP address should be directed
  • ttl – TTL for this record
  • label – A unique label for this DSFPTRRecord
  • weight – Weight for this DSFPTRRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFPXRecord(preference, map822, mapx400, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An PXRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(preference, map822, mapx400, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFPXRecord object

Parameters:
  • preference – Sets priority for processing records of the same type. Lowest value is processed first.
  • map822 – mail hostname
  • mapx400 – The domain name derived from the X.400 part of MCGAM
  • ttl – TTL for this record
  • label – A unique label for this DSFPXRecord
  • weight – Weight for this DSFPXRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFNSAPRecord(nsap, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An NSAPRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(nsap, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFNSAPRecord object

Parameters:
  • nsap – Hex-encoded NSAP identifier
  • ttl – TTL for this record
  • label – A unique label for this DSFNSAPRecord
  • weight – Weight for this DSFNSAPRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFRPRecord(mbox, txtdname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An RPRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(mbox, txtdname, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFRPRecord object

Parameters:
  • mbox – Email address of the Responsible Person.
  • txtdname – Hostname where a TXT record exists with more information on the responsible person.
  • ttl – TTL for this record
  • label – A unique label for this DSFRPRecord
  • weight – Weight for this DSFRPRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFNSRecord(nsdname, service_class='', ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An NSRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(nsdname, service_class='', ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFNSRecord object

Parameters:
  • nsdname – Hostname of the authoritative Nameserver for the zone
  • service_class – Hostname of the authoritative Nameserver for the zone
  • ttl – TTL for this record
  • label – A unique label for this DSFNSRecord
  • weight – Weight for this DSFNSRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFSPFRecord(txtdata, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An SPFRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(txtdata, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFSPFRecord object

Parameters:
  • txtdata – Free text containing SPF record information
  • ttl – TTL for this record
  • label – A unique label for this DSFSPFRecord
  • weight – Weight for this DSFSPFRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFSRVRecord(port, priority, target, rr_weight, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An SRVRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(port, priority, target, rr_weight, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFSRVRecord object

Parameters:
  • port – Indicates the port where the service is running
  • priority – Numeric value for priority usage. Lower value takes precedence over higher value where two records of the same type exist on the zone/node
  • target – The domain name of a host where the service is running on the specified port
  • rr_weight – Secondary prioritizing of records to serve. Records of equal priority should be served based on their weight. Higher values are served more often
  • ttl – TTL for this record
  • label – A unique label for this DSFSRVRecord
  • weight – Weight for this DSFSRVRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFSSHFPRecord(fptype, algorithm, fingerprint, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An SSHFPRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(fptype, algorithm, fingerprint, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFSSHFPRecord object

Parameters:
  • algorithm – Numeric value representing the public key encryption algorithm which will sign the zone.
  • fptype – FingerPrint Type
  • fingerprint – fingerprint value
  • ttl – TTL for this record
  • label – A unique label for this DSFSSHFPRecord
  • weight – Weight for this DSFSSHFPRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served
class dyn.tm.services.dsf.DSFTXTRecord(txtdata, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

An TXTRecord object which is able to store additional data for use by a TrafficDirector service.

__init__(txtdata, ttl=0, label=None, weight=1, automation='auto', endpoints=None, endpoint_up_count=None, eligible=True, **kwargs)[source]

Create a DSFTXTRecord object

Parameters:
  • txtdata – Plain text data to be served by this DSFTXTRecord
  • ttl – TTL for this record
  • label – A unique label for this DSFTXTRecord
  • weight – Weight for this DSFTXTRecord
  • automation – Defines how eligible can be changed in response to monitoring. Must be one of ‘auto’, ‘auto_down’, or ‘manual’
  • endpoints – Endpoints are used to determine status, torpidity, and eligible in response to monitor data
  • endpoint_up_count – Number of endpoints that must be up for the Record status to be ‘up’
  • eligible – Indicates whether or not the Record can be served

4.5.4.2.1.1. DSFRecord Examples

The following examples highlight how to use the DSFRecord classes to get/create/update/delete DSFRecord’s on the dyn.tm System and how to edit these objects from within a Python script. We’ll stick to a simple DSFARecord in our examples.

4.5.4.2.1.1.1. Create DSF__Record

We’ll assume you already have a DSFRecordset object called record_set in existence for this example.

>>> from dyn.tm.services.dsf import DSFARecord
>>> record = DSFARecord('10.1.1.1', label='TEST RECORD', weight=1, automation='auto', eligible=True)
>>> #Now, we create this A record by adding it to an existing record_set
>>> record.add_to_record_set(record_set) #This is automatically published.

4.5.4.2.1.1.2. Update DSF__Record

To change the record IP address of the record we just created, we can use one of our setters.

>>> record.address = '20.1.1.1' #This gets published implicitly
>>> #Check to see if it really changed.
>>> record.address
>>>'20.1.1.1'

Implicit publishing can be turned off for any object if that is undesirable, check Modifying Traffic Director Service Properties below for an example and explanation

4.5.4.2.1.1.3. Get All DSF__Record

To get all DSFRecord: from a certain TrafficDirector:

>>> from dyn.tm.services.dsf import get_all_records
>>> #Pass in a :class:`TrafficDirector`: instance to the following call:
>>> get_all_records(td)

4.5.4.2.1.1.4. Delete DSF__Record

To Delete your DSFRecord:

>>> record.delete()

4.5.4.2.2. DSFRecordSet

class dyn.tm.services.dsf.DSFRecordSet(rdata_class, label=None, ttl=None, automation=None, serve_count=None, fail_count=None, trouble_count=None, eligible=None, dsf_monitor_id=None, records=None, **kwargs)[source]

A Collection of DSFRecord Type objects belonging to a DSFFailoverChain

__init__(rdata_class, label=None, ttl=None, automation=None, serve_count=None, fail_count=None, trouble_count=None, eligible=None, dsf_monitor_id=None, records=None, **kwargs)[source]

Create a new DSFRecordSet object

Parameters:
  • rdata_class – The type of rdata represented by this DSFRecordSet
  • label – A unique label for this DSFRecordSet
  • ttl – Default TTL for DSFRecord’s within this DSFRecordSet
  • automation – Defines how eligible can be changed in response to monitoring
  • serve_count – How many Records to serve out of this DSFRecordSet
  • fail_count – The number of Records that must not be okay before this DSFRecordSet becomes ineligible.
  • trouble_count – The number of Records that must not be okay before this DSFRecordSet becomes in trouble.
  • eligible – Indicates whether or not this DSFRecordSet can be served.
  • dsf_monitor_id – The unique system id of the DSF Monitor attached to this DSFRecordSet
  • records – A list of DSFRecord’s within this DSFRecordSet
  • kwargs – Used for manipulating additional data to be specified by the creation of other system objects.
add_to_failover_chain(failover_chain, service=None, publish=True, notes=None)[source]

Creates and links this DSFRecordSet to the passed in DSFFailoverChain Object

Parameters:
  • failover_chain – Can either be the dsf_record_set_failover_chain_id or a DSFFailoverChain Object.
  • service – Only necessary is rs_chain is passed in as a string. This can be a TrafficDirector Object. or the _service_id
  • publish – Publish on execution (Default = True)
  • notes – Optional Zone publish Notes
automation

Defines how eligible can be changed in response to monitoring

delete(notes=None, publish=True)[source]

Delete this DSFRecordSet from the Dynect System :param notes: Optional zone publish notes :param publish: Publish at run time. Default is True

dsf_id

The unique system id of the TrafficDirector This DSFRecordSet is attached to

dsf_monitor_id

The unique system id of the DSF Monitor attached to this DSFRecordSet

eligible

Indicates whether or not this DSFRecordSet can be served

fail_count

The number of Records that must not be okay before this DSFRecordSet becomes ineligible.

implicitPublish

Toggle for this specific DSFRecordSet for turning on and off implicit Publishing for record Updates.

implicit_publish

Toggle for this specific DSFRecordSet for turning on and off implicit Publishing for record Updates.

label

A unique label for this DSFRecordSet

publish(notes=None)[source]

Publish changes to TrafficDirector. :param notes: Optional Note that will be added to the zone notes of

zones attached to this service.
publish_note

Returns Current Publish Note, which will be used on the next publish action

rdata_class

The rdata property is a read-only attribute

record_set_id

The unique system id of this DSFRecordSet

records

The list of DSFRecord types that are stored in this DSFRecordSet

refresh()[source]

Pulls data down from Dynect System and repopulates DSFRecordSet

serve_count

How many Records to serve out of this DSFRecordSet

set_monitor(monitor)[source]

For attaching a DSFMonitor to this record_set :param monitor: a DSFMonitor or string of the dsf_monitor_id

to attach to this record_set
status

The current status of this DSFRecordSet

to_json(svc_id=None, skip_svc=False)[source]

Convert this DSFRecordSet to a JSON blob

trouble_count

The number of Records that must not be okay before this DSFRecordSet becomes in trouble.

ttl

Default TTL for DSFRecord’s within this DSFRecordSet

4.5.4.2.2.1. DSFRecordSet Examples

The following examples highlight how to use the DSFRecordSet classes to get/create/update/delete DSFRecordSet’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.2.1.1. Create DSFRecordSet

We’ll assume you already have a DSFFailoverChain object named failover_chain in existence for this example.

>>> from dyn.tm.services.dsf import DSFRecordSet
>>> #set up recordset for A records,
>>> record_set = DSFRecordSet('A', label='Record_set_test', ttl=60)
>>> #Now, we create this record_set by adding it to an existing failover_chain
>>> record_set.add_to_failover_chain(failover_chain) #This is automatically published.

To make the record_set and its child A records in one create action:

>>> from dyn.tm.services.dsf import DSFRecordSet, DSFARecord
>>> #Create A Record Prototypes
>>> record1 = DSFARecord('10.1.1.1', label='TEST RECORD 10', weight=1, automation='auto', eligible=True)
>>> record2 = DSFARecord('20.1.1.1', label='TEST RECORD 20', weight=1, automation='auto', eligible=True)
>>> #set up record_set for A records and pass in the two record protypes,
>>> record_set = DSFRecordSet('A', label='Record_set_test', ttl=60, records=[record1, record2])
>>> #Now, we create this record_set by adding it to an existing failover_chain
>>> record_set.add_to_failover_chain(failover_chain) #This is automatically published.

As with all other DSF objects, the prototypes record1 record2 can’t be used in CRUD operations. You must access these objects within the record_set.

>>> record_set.records
>>>[<ARecord>: 10.1.1.1, <ARecord>: 20.1.1.1]

4.5.4.2.2.1.2. Update DSFRecordSet

To change the label for the above DSFRecordset:

>>> record_set.label = 'New Name'  #This gets published implicitly
>>> #Check to see if it really changed.
>>> record_set.label.label
>>>'New Name'

Implicit publishing can be turned off for any object if that is undesirable, check Modifying Traffic Director Service Properties below for an example and explanation

4.5.4.2.2.1.3. Adding DSFMonitor to DSFRecordSet

To add a DSFMonitor to your DSFRecordset:

Existing DSFRecordset:

>>> from dyn.tm.services.dsf import DSFMonitor
>>> #create your monitor
>>> monitor = DSFMonitor('testmonitor', 'HTTP', 1, 60, 1, port=80)
>>> #or get an existing one (example)
>>> from dyn.tm.services.dsf import get_all_dsf_monitors
>>> monitor = get_all_dsf_monitors()[0]
>>> #Now attach monitor to record_set
>>> record_set.set_monitor(monitor)

New DSFRecordset:

>>> #Create or get your monitor object as above.
>>> record_set = DSFRecordSet('A', label='Record_set_test', ttl=60, dsf_monitor_id=monitor.dsf_monitor_id)
>>> record_set.add_to_failover_chain(failover_chain) #create record_set

4.5.4.2.2.1.4. Get All DSFRecordSet

To get all DSFRecordSet: from a certain TrafficDirector:

>>> from dyn.tm.services.dsf import get_all_record_sets
>>> #Pass in a :class:`TrafficDirector`: instance to the following call:
>>> get_all_record_sets(td)

4.5.4.2.2.1.5. Delete DSFRecordSet

To Delete your DSFRecordset:

>>> record_set.delete()

This will delete all child records attached to this object!

4.5.4.2.3. DSFFailoverChain

class dyn.tm.services.dsf.DSFFailoverChain(label=None, core=None, record_sets=None, **kwargs)[source]

docstring for DSFFailoverChain

__init__(label=None, core=None, record_sets=None, **kwargs)[source]

Create a DSFFailoverChain object

Parameters:
add_to_response_pool(response_pool, service=None, publish=True, notes=None)[source]

Creates and Adds this DSFFailoverChain to a TrafficDirector service.

Parameters:
  • response_pool – Can either be the response_pool_id or a DSFResponsePool Object.
  • service – Only necessary when response_pool is passed as a string. Can either be the service_id or a TrafficDirector
  • publish – Publish on execution (Default = True)
  • notes – Optional Zone publish Notes
core

Indicates whether or not the contained DSFRecordSet’s are core record sets.

delete(notes=None, publish=True)[source]

Delete this DSFFailoverChain from the Dynect System :param notes: Optional zone publish notes :param publish: Publish at run time. Default is True

dsf_id

The unique system id of the TrafficDirector This DSFFailoverChain is attached to

failover_chain_id

The unique system id of this DSFFailoverChain

implicitPublish

Toggle for this specific DSFFailoverChain for turning on and off implicit Publishing for record Updates.

implicit_publish

Toggle for this specific DSFFailoverChain for turning on and off implicit Publishing for record Updates.

label

A unique label for this DSFFailoverChain

publish(notes=None)[source]

Publish changes to TrafficDirector. :param notes: Optional Note that will be added to the zone

notes of zones attached to this service.
publish_note

Returns Current Publish Note, which will be used on the next publish action

record_sets

A list of DSFRecordSet connected to this DSFFailvoerChain

refresh()[source]

Pulls data down from Dynect System and repopulates DSFFailoverChain

response_pool_id

The unique system id of the DSFResponsePool this DSFFailoverChain is attached to

to_json(svc_id=None, skip_svc=False)[source]

Convert this DSFFailoverChain to a JSON blob

4.5.4.2.3.1. DSFFailoverChain Examples

The following examples highlight how to use the DSFFailoverChain classes to get/create/update/delete DSFFailoverChain’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.3.1.1. Create DSFFailoverChain

We’ll assume you already have a DSFResponsePool object named response_pool in existence for this example.

>>> from dyn.tm.services.dsf import DSFFailoverChain
>>> #set up failover_chain
>>> failover_chain = DSFFailoverChain(label='TEST Chain')
>>> #Now, we create this failover_chain by adding it to an existing response_pool
>>> failover_chain.add_to_response_pool(response_pool) #This is automatically published.

To make the failover_chain and its child record_set in one create action:

>>> from dyn.tm.services.dsf import DSFFailoverChain, DSFRecordSet
>>> #set up record_set prototype
>>> record_set = DSFRecordSet('A', label='Record_set_test', ttl=60,)
>>> #set up failover_chain and pass in the record_set prototype
>>> failover_chain = DSFFailoverChain(label='TEST Chain', record_sets=[record_set])
>>> #Now, we create this failover_chain by adding it to an existing response_pool
>>> failover_chain.add_to_response_pool(response_pool) #This is automatically published.

You can continue nesting beyond record_set by adding records = [record1…] to the record_set prototype. See TrafficDirector example for a larger example,

As with all other DSF objects, the prototypes record_set can’t be used in CRUD operations. You must access these objects within the failover_chain.

>>> failover_chain.record_sets
>>>[<DSFRecordSet>: RDClass: A, Label: Record_set_test, ID: r6e1_IkchB-Yp93rAEClo8QbZzA]

4.5.4.2.3.1.2. Update DSFFailoverChain

To change the label for the above DSFFailoverChain:

>>> failover_chain.label = 'New Name'  #This gets published implicitly
>>> #Check to see if it really changed.
>>> failover_chain.label
>>>'New Name'

Implicit publishing can be turned off for any object if that is undesirable, check Modifying Traffic Director Service Properties below for an example and explanation

4.5.4.2.3.1.3. Get All DSFFailoverChain

To get all DSFFailoverChain: from a certain TrafficDirector:

>>> from dyn.tm.services.dsf import get_all_failover_chains
>>> #Pass in a :class:`DSFFailoverChain`: instance to the following call:
>>> get_all_failover_chains(td)

4.5.4.2.3.1.4. Delete DSFFailoverChain

To Delete your DSFFailoverChain:

>>> failover_chain.delete()

This will delete all child records attached to this object!

4.5.4.2.4. DSFResponsePool

class dyn.tm.services.dsf.DSFResponsePool(label, core_set_count=1, eligible=True, automation='auto', dsf_ruleset_id=None, index=None, rs_chains=None, **kwargs)[source]

docstring for DSFResponsePool

__init__(label, core_set_count=1, eligible=True, automation='auto', dsf_ruleset_id=None, index=None, rs_chains=None, **kwargs)[source]

Create a DSFResponsePool object

Parameters:
  • label – A unique label for this DSFResponsePool
  • core_set_count – If fewer than this number of core record sets are eligible, status will be set to fail
  • eligible – Indicates whether or not the DSFResponsePool can be served
  • automation – Defines how eligible can be changed in response to monitoring
  • dsf_ruleset_id – Unique system id of the Ruleset this DSFResponsePool is attached to
  • index – When specified with dsf_ruleset_id, indicates the position of the DSFResponsePool
  • rs_chains – A list of DSFFailoverChain that are defined for this DSFResponsePool
automation

Defines how eligiblity can be changed in response to monitoring

core_set_count

If fewer than this number of core record sets are eligible, status will be set to fail

create(service, publish=True, notes=None)[source]

Adds this DSFResponsePool to the passed in TrafficDirector :param service: a TrafficDirector or id string for the

TrafficDirector you wish to add this DSFResponsePool to.
Parameters:
  • publish – publish at execution time. Default = True
  • notes – Optional Zone publish Notes
delete(notes=None, publish=True)[source]

Delete this DSFResponsePool from the DynECT System :param notes: Optional zone publish notes :param publish: Publish at run time. Default is True

dsf_id

The unique system id of the TrafficDirector This DSFResponsePool is attached to

eligible

Indicates whether or not the DSFResponsePool can be served

failover_chains

A list of DSFFailoverChain that are defined for this DSFResponsePool

implicitPublish

Toggle for this specific DSFResponsePool for turning on and off implicit Publishing for record Updates.

implicit_publish

Toggle for this specific DSFResponsePool for turning on and off implicit Publishing for record Updates.

label

A unique label for this DSFResponsePool

publish(notes=None)[source]

Publish changes to TrafficDirector. :param notes: Optional Note that will be added to the zone notes of zones attached to this service.

publish_note

Returns Current Publish Note, which will be used on the next publish action

refresh()[source]

Pulls data down from Dynect System and repopulates DSFResponsePool

response_pool_id

The Unique system id of this DSFResponsePool

rs_chains

A list of DSFFailoverChain that are defined for this DSFResponsePool (legacy call)

ruleset_ids

List of Unique system ids of the DSFRuleset`s this :class:`DSFResponsePool is attached to

to_json(svc_id=None, skip_svc=False)[source]

Convert this DSFResponsePool to a JSON blob

4.5.4.2.4.1. DSFResponsePool Examples

The following examples highlight how to use the DSFResponsePool classes to get/create/update/delete DSFResponsePool’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.4.1.1. Create DSFResponsePool

Because the DSFReponsePool is at the bottom of the tree, there is nothing to attach to it except for the TrafficDirector service.

>>> from dyn.tm.services.dsf import DSFResponsePool
>>> #set up Response Pool with label
>>> response_pool = DSFResponsePool(label='TEST Pool')
>>> #Now, we create this response_pool by passing in the TrafficDirector object
>>> response_pool.create(td) #This is automatically published.

To make the response_pool and its child failover_chain in one create action:

>>> from dyn.tm.services.dsf import DSFFailoverChain, DSFResponsePool
>>> #set up failover_chain prototype
>>> failover_chain = DSFFailoverChain(label='TEST Chain')
>>> #set up response_pool and pass in the failover_chain prototype
>>> response_pool = DSFResponsePool(label='TEST Pool', rs_chains=[failover_chain])
>>> #Now, we create this response_pool by adding it to an existing TrafficDirector service
>>> response_pool.create(td) #This is automatically published.

You can continue nesting beyond failover_chain by adding records_set = [record_set1…] to the failover_chain prototype. See TrafficDirector example for a larger example,

As with all other DSF objects, the prototypes failover_chain can’t be used in CRUD operations. You must access these objects within the response_pool.

>>> response_pool.failover_chains
>>>[<DSFFailoverChain>: Label: TEST Chain, ID: AFUQpP2GRADINM1W12j_AVp_AX0]

4.5.4.2.4.1.2. Update DSFResponsePool

To change the label for the above DSFResponsePool:

>>> response_pool.label = 'New Name'  #This gets published implicitly
>>> #Check to see if it really changed.
>>> response_pool.label
>>>'New Name'

Implicit publishing can be turned off for any object if that is undesirable, check Modifying Traffic Director Service Properties below for an example and explanation

4.5.4.2.4.1.3. Get All DSFResponsePool

To get all DSFResponsePool: from a certain TrafficDirector:

>>> from dyn.tm.services.dsf import get_all_response_pools
>>> #Pass in a :class:`DSFResponsePool`: instance to the following call:
>>> get_all_response_pools(td)

4.5.4.2.4.1.4. Delete DSFResponsePool

To Delete your DSFResponsePool:

>>> response_pool.delete()

This will delete all child records attached to this object!

4.5.4.2.5. DSFRuleset

class dyn.tm.services.dsf.DSFRuleset(label, criteria_type, response_pools, criteria=None, failover=None, **kwargs)[source]

docstring for DSFRuleset

__init__(label, criteria_type, response_pools, criteria=None, failover=None, **kwargs)[source]

Create a DSFRuleset object

Parameters:
  • label – A unique label for this DSFRuleset
  • criteria_type – A set of rules describing what traffic is applied to the DSFRuleset
  • criteria – Varied depending on the specified criteria_type
  • failover – IP address or Hostname for a last resort failover.
  • response_pools – A list of DSFResponsePool’s for this DSFRuleset
add_failover_ip(ip, publish=True)[source]

Adds passed in DSFResponsePool to the end of this DSFRuleSet. This effectively creates a special new Record chain with a single IP. It can be accessed as a responce pool with label equal to the ip passed in.

Parameters:publish – Publish on execution (Default = True)
add_response_pool(response_pool, index=0, publish=True)[source]

Adds passed in DSFResponsePool to this DSFRuleSet. By default this adds it to the front of the list.

Parameters:
  • response_pool – Can either be the response_pool_id or a DSFResponsePool Object.
  • index – where in the list of response pools to place this pool. 0 is the first position, 0 is the default.
  • publish – Publish on execution (Default = True)
create(service, index=None, publish=True, notes=None)[source]

Adds this DSFRuleset to the passed in TrafficDirector

Parameters:
  • service – a TrafficDirector or id string for the TrafficDirector you wish to add this DSFRuleset to.
  • index – in what position to serve this ruleset. 0 = first.
  • publish – publish at execution time. Default = True
  • notes – Optional Zone publish Notes
criteria

The criteria rules, will be varied depending on the specified criteria_type

criteria_type

A set of rules describing what traffic is applied to the DSFRuleset

delete(notes=None, publish=True)[source]

Remove this DSFRuleset from it’s associated TrafficDirector Service :param notes: Optional zone publish notes :param publish: Publish at run time. Default is True

dsf_id

The unique system id of the TrafficDirector This DSFRuleset is attached to

implicitPublish

Toggle for this specific DSFRuleset for turning on and off implicit Publishing for record Updates.

implicit_publish

Toggle for this specific DSFRuleset for turning on and off implicit Publishing for record Updates.

label

A unique label for this DSFRuleset

order_response_pools(pool_list, publish=True)[source]

For reordering the ruleset list. simply pass in a list of :class:`DSFResponcePool`s in the order you wish them to failover.

Parameters:
  • pool_list – ordered list of DSFResponcePool
  • publish – Publish on execution. default = True
publish(notes=None)[source]

Publish changes to TrafficDirector. :param notes: Optional Note that will be added to the zone notes

of zones attached to this service.
publish_note

Returns Current Publish Note, which will be used on the next publish action

refresh()[source]

Pulls data down from Dynect System and repopulates DSFRuleset

remove_response_pool(response_pool, publish=True)[source]

Removes passed in DSFResponsePool from this DSFRuleSet

Parameters:
  • response_pool – Can either be the response_pool_id or a DSFResponsePool Object.
  • publish – Publish on execution (Default = True)
response_pools

A list of DSFResponsePool’s for this DSFRuleset

ruleset_id

The unique system id of this DSFRuleset

4.5.4.2.5.1. DSFRuleset Examples

The following examples highlight how to use the DSFRuleset classes to get/create/update/delete DSFRuleset’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.5.1.1. Create DSFRuleset

The DSFRuleset contains zero or more Response Pools, and belongs to the TrafficDirector service

>>> from dyn.tm.services.dsf import DSFRuleset
>>> #Make an empty ruleset:
>>> ruleset = DSFRuleset('The Rules', criteria_type='always', response_pools=[])

To make the ruleset and its create-link a response_pool in one create action:

>>> from dyn.tm.services.dsf import DSFRuleset, DSFResponsePool
>>> response_pool = DSFResponsePool(label='TEST Pool')
>>> #Make an empty ruleset:
>>> ruleset = DSFRuleset('The Rules', criteria_type='always', response_pools=[response_pool])

You can continue nesting beyond response_pool by adding rs_chain = [failover_chain1…] to the response_pool prototype. See TrafficDirector example for a larger example,

As with all other DSF objects, the prototypes response_pool can’t be used in CRUD operations. You must access these objects within the ruleset.

>>> ruleset.response_pools
>>>[<DSFResponsePool>: Label: TEST Pool, ID: NXAdxSrodSCUO_p9vbbpKuXJIOw]

4.5.4.2.5.1.2. Adding/Deleting/Modifying DSFResponsePools to DSFRuleset

The order of :class:`DSFResponsePool`s is important in rulesets, so we have a number of functions for handling this. For this example assume we have 4 response pools pre-existing.

>>> #Lets add all 4 Response Pools to the ruleset.
>>> ruleset.add_response_pool(pool1) #First Pool
>>> ruleset.add_response_pool(pool2) #added to the front of the list
>>> ruleset.add_response_pool(pool3) #added to the front of the list
>>> #If we want pool4 to be at the back of the list we can specify the index.
>>> ruleset.add_response_pool(pool4, index=3)
>>> ruleset.response_pools
>>>[<DSFResponsePool>: Label: pool3, ID: 4Vu7lCEb3iDuATWq5Q6-5P-RAfU,
...<DSFResponsePool>: Label: pool2, ID: LPDIZfbr0gEVg-AR31CNE_wVDIg,
...<DSFResponsePool>: Label: pool1, ID: JybChuDQtCWSyADLFfqp2JKFYoE,
...<DSFResponsePool>: Label: pool4, ID: 3a-eVZYaRt3NeNxUXyA87OroswQ]

If you need to re-order your list, there is a helper function

>>> ruleset.order_response_pools([pool1,pool2,pool3,pool4])
>>> ruleset.response_pools
>>> [<DSFResponsePool>: Label: pool1, ID: JybChuDQtCWSyADLFfqp2JKFYoE,
...<DSFResponsePool>: Label: pool2, ID: LPDIZfbr0gEVg-AR31CNE_wVDIg,
...<DSFResponsePool>: Label: pool3, ID: 4Vu7lCEb3iDuATWq5Q6-5P-RAfU,
...<DSFResponsePool>: Label: pool4, ID: 3a-eVZYaRt3NeNxUXyA87OroswQ]
And, if you need to Delete a DSFResponsePool from the ruleset
>>> ruleset.remove_response_pool(pool3)
>>>[<DSFResponsePool>: Label: pool1, ID: JybChuDQtCWSyADLFfqp2JKFYoE,
...<DSFResponsePool>: Label: pool2, ID: LPDIZfbr0gEVg-AR31CNE_wVDIg,
...<DSFResponsePool>: Label: pool4, ID: 3a-eVZYaRt3NeNxUXyA87OroswQ]

4.5.4.2.5.1.3. Adding/manipulating a failover IP to DSFRuleset

DSFRulesets have the option to failover to a static IP. Behind the scenes, this is essential a full
ResponsePool to Record chain with one single host or IP. when manipulating this value, keep that in mind.

Assume we have the same service as the Adding/Deleting/Modifying DSFResponsePools to DSFRuleset example.

>>> #To Add the failover IP.
>>> ruleset.add_failover_ip('1.2.3.4')
>>> # Notice how its essentially a Response_pool -> Record chain -- this is always added to the end of the response pool list.
>>> ruleset.response_pools
>>>[<DSFResponsePool>: Label: pool1, ID: JybChuDQtCWSyADLFfqp2JKFYoE,
...<DSFResponsePool>: Label: pool2, ID: LPDIZfbr0gEVg-AR31CNE_wVDIg,
...<DSFResponsePool>: Label: pool4, ID: 3a-eVZYaRt3NeNxUXyA87OroswQ,
...<DSFResponsePool>: Label: 1.2.3.4, ID: wyUslh6c9eTXFvu7OSfW7S6Hj9I]
>>> # To modify the IP:
>>> ruleset.response_pools[3].rs_chains[0].record_sets[0].records[0].address = '10.10.10.10'
>>> #The labels for the chain will still say 1.2.3.4, but the served records will be 10.10.10.10

4.5.4.2.5.1.4. Update DSFRuleset

To change the label for the above DSFRuleset:

>>> ruleset.label = 'New Name'  #This gets published implicitly
>>> #Check to see if it really changed.
>>> ruleset.label
>>>'New Name'

4.5.4.2.5.1.5. Get All DSFRuleset

To get all DSFRuleset: from a certain TrafficDirector:

>>> from dyn.tm.services.dsf import get_all_rulesets
>>> #Pass in a :class:`DSFRuleset`: instance to the following call:
>>> get_all_rulesets(td)

4.5.4.2.5.1.6. Delete DSFRuleset

To Delete your DSFRuleset:

>>> ruleset.delete()

This will NOT delete child records, however any child response pools and children that are not in other DSFRuleset`s may not be displayed in the :class:`TrafficDirector object as it builds its trees from the Rulesets. see Traffic Director SDK Caveats

4.5.4.2.6. DSFMonitor

class dyn.tm.services.dsf.DSFMonitor(*args, **kwargs)[source]

A Monitor for a TrafficDirector Service

__init__(*args, **kwargs)[source]

Create a new DSFMonitor object

Parameters:
  • label – A unique label to identify this DSFMonitor
  • protocol – The protocol to monitor. Must be one of ‘HTTP’, ‘HTTPS’, ‘PING’, ‘SMTP’, or ‘TCP’
  • response_count – The number of responses to determine whether or not the endpoint is ‘up’ or ‘down’
  • probe_interval – How often to run this DSFMonitor
  • retries – How many retries this DSFMonitor should attempt on failure before giving up.
  • active – Indicates if this DSFMonitor is active
  • options – Additional options pertaining to this DSFMonitor
  • endpoints – A List of DSFMonitorEndpoint’s that are associated with this DSFMonitor
active

Returns whether or not this DSFMonitor is active. Will return either ‘Y’ or ‘N’

delete()[source]

Delete an existing DSFMonitor from the DynECT System

dsf_monitor_id

The unique system id of this DSFMonitor

endpoints

A list of the endpoints (and their statuses) that this DSFMonitor is currently monitoring.

label

A unique label to identify this DSFMonitor

options

Additional options pertaining to this DSFMonitor

probe_interval

How often to run this DSFMonitor

protocol

The protocol to monitor. Must be one of ‘HTTP’, ‘HTTPS’, ‘PING’, ‘SMTP’, or ‘TCP’

response_count

The minimum number of agents reporting the host as up for failover not to occur. Must be 0, 1 or 2

retries

How many retries this DSFMonitor should attempt on failure before giving up.

4.5.4.2.6.1. DSFMonitor Examples

The following examples highlight how to use the DSFMonitor classes to get/create/update/delete DSFMonitor’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.6.1.1. Create DSFMonitor

Unlike most of the other DSF objects, DSFMonitor publishes when the object is created.

>>> from dyn.tm.services.dsf import DSFMonitor
>>> monitor = DSFMonitor('MonitorLabel', 'HTTP', 1, 60, 1, port=8080)
>>> monitor.dsf_monitor_id
>>> u'SE-6GKx_tEBHyL4G_-i28R2QiNs'

4.5.4.2.6.1.2. Update DSFMonitor

To change the label for the above DSFRuleset:

>>> monitor.label = 'NewMonitorName'  #Changes are immediate
>>> #Check to see if it really changed.
>>> monitor.label
>>>'NewMonitorName'

4.5.4.2.6.1.3. Add To DSFMonitor to DSFRecordSet

See DSFRecordSet example.

4.5.4.2.6.1.4. Get All DSFMonitor

To get all DSFMonitor:

>>> from dyn.tm.services.dsf import get_all_dsf_monitors
>>> #Not a child class, monitors are their own entity, so no need to pass in a :class:`TrafficDirector`:
>>> get_all_dsf_monitors()

4.5.4.2.6.1.5. Delete DSFMonitor

To Delete your DSFMonitor:

>>> monitor.delete()

4.5.4.2.7. DSFNotifier

class dyn.tm.services.dsf.DSFNotifier(*args, **kwargs)[source]
__init__(*args, **kwargs)[source]

Create a Notifier object

Parameters:
  • label
  • recipientslist of Contact Names
  • dsf_services
  • monitor_services
add_recipient(new_recipient, format='email')[source]
del_recipient(recipient)[source]
delete()[source]

Delete this DSFNotifier from the Dynect System

dsf_service_ids
label

Link ID connecting thie Notifier to TD service

monitor_service_ids
recipients
to_json()[source]

4.5.4.2.7.1. DSFNotifier Examples

The following examples highlight how to use the DSFNotifier classes to get/create/update/delete DSFNotifier’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.7.1.1. Create DSFNotifier

Unlike most of the other DSF objects, DSFNotifier publishes when the object is created.

>>> from dyn.tm.services.dsf import DSFNotifier
>>> #When passing in recipients, pass in a list of strings(s) of your contact(s) nickname(s)
>>> notifier = DSFNotifier('Notifier', recipients=['youruser'])
>>> notifier.dsf_notifier_id
>>> u'BHyL4GxatEBHyR2QiNT28R2QiNs'
You can add the new notifier directly to a TrafficDirector as well
>>> from dyn.tm.services.dsf import DSFNotifier
>>> #When passing in recipients, pass in a list of strings(s) of your contact(s) nickname(s)
>>> notifier = DSFNotifier('Notifier', recipients=['youruser'], dsf_services=[td.service_id])
>>> notifier.dsf_notifier_id
>>> u'xatEBHyQiNT28R2QiyR2QiNt28R'

4.5.4.2.7.1.2. Update DSFNotifier

To change the label for the above DSFRuleset:

>>> notifier.label = 'NewNotifierName'  #Changes are immediate
>>> #Check to see if it really changed.
>>> notifier.label
>>>'NewNotifierName'

4.5.4.2.7.1.3. Get All DSFNotifier

To get all DSFNotifier:

>>> from dyn.tm.services.dsf import get_all_dsf_notifiers
>>> #Not a child class, notifiers are their own entity, so no need to pass in a :class:`TrafficDirector`:
>>> get_all_dsf_notifiers()

4.5.4.2.7.1.4. Delete DSFNotifier

To Delete your DSFNotifier:

>>> notifier.delete()

4.5.4.2.8. Traffic Director

class dyn.tm.services.dsf.TrafficDirector(*args, **kwargs)[source]

Traffic Director is a DNS based traffic routing and load balancing service that is Geolocation aware and can support failover by monitoring endpoints.

__init__(*args, **kwargs)[source]

Create a TrafficDirector object

Parameters:
  • label – A unique label for this TrafficDirector service
  • ttl – The default TTL to be used across this service
  • publish – If Y, service will be published on creation
  • notes – Optional Publish Zone Notes.
  • nodes – A Node Object, a zone, FQDN pair in a hash, or a list containing those two things (can be mixed) that are to be linked to this TrafficDirector service:
  • notifiers – A list of notifier ids associated with this TrafficDirector service
  • rulesets – A list of DSFRulesets that are defined for this TrafficDirector service
add_node(node)[source]

A DSFNode object, or a zone, FQDN pair in a hash to be added to this TrafficDirector service

add_notifier(notifier, notes=None)[source]

Links the DSFNotifier with the specified id to this Traffic Director service, Accepts DSFNotifier or Notifier or the notifier public id.

all_failover_chains

Returns All DSFFailoverChain in TrafficDirector

all_record_sets

Returns All DSFRecordSet in TrafficDirector

all_records

Returns All DSFRecord in TrafficDirector

all_response_pools

Returns All DSFResponsePool in TrafficDirector

all_rulesets

Returns All DSFRuleset in TrafficDirector

del_notifier(notifier, notes=None)[source]

delinks the DSFNotifier with the specified id to this Traffic Director service. Accepts DSFNotifier or Notifier.

delete()[source]

Delete this TrafficDirector from the DynECT System :param notes: Optional zone publish notes

failover_chains

A list of this TrafficDirector Services DSFFailoverChain’s

implicitPublish

Toggle for this specific TrafficDirector for turning on and off implicit Publishing for record Updates.

implicit_publish

Toggle for this specific TrafficDirector for turning on and off implicit Publishing for record Updates.

label

A unique label for this TrafficDirector service

nodeObjects

A list of DSFNode Objects that are linked to this TrafficDirector service

node_objects

A list of DSFNode Objects that are linked to this TrafficDirector service

nodes

A list of hashes of zones, fqdn for each DSF node that is linked to this TrafficDirector service

notifiers

A list of names of DSFNotifier associated with this TrafficDirector service

order_rulesets(ruleset_list, publish=True)[source]

For reordering the ruleset list. simply pass in a list of :class:`DSFRulesets`s in the order you wish them to be served.

Parameters:
  • ruleset_list – ordered list of DSFRulesets
  • publish – Publish on execution. default = True
publish(notes=None)[source]

Publish changes to TrafficDirector. :param notes: Optional Note that will be added to the zone notes of zones attached to this service.

publish_note

Returns Current Publish Note, which will be used on the next publish action

record_sets

A list of this TrafficDirector Services DSFRecordSet’s

records

A list of this TrafficDirector Services’ DSFRecords

refresh()[source]

Pulls data down from Dynect System and repopulates TrafficDirector

remove_node(node)[source]

A DSFNode object, or a zone, FQDN pair in a hash to be removed to this TrafficDirector service

remove_orphans()[source]

Remove Record Set Chains which are no longer referenced by a DSFResponsePool

replace_all_rulesets(rulesets)[source]

This request will replace all rulesets with a new list of rulesets.

Parameters:rulesets – a list of rulesets :class:DSFRuleset to be published

to the service Warning! This call takes extra time as it is several api calls.

replace_one_ruleset(ruleset)[source]

This request will replace a single ruleset and maintain the order of the list.

Warning! This call takes extra time as it is several api calls.

Parameters:ruleset – A single object of :class:DSFRuleset` The replacement

is keyed by the DSFRuleset label value.

response_pools

A list of this TrafficDirector Services DSFResponsePool’s

revert_changes()[source]

Clears the changeset for this service and reverts all non-published changes to their original state

rulesets

A list of DSFRulesets that are defined for this TrafficDirector service

service_id

The unique System id of this DSF Service

ttl

The default TTL to be used across this service

4.5.4.2.8.1. Traffic Director Examples

The following examples highlight how to use the TrafficDirector class to get/create/update/delete TrafficDirector’s on the dyn.tm System and how to edit these objects from within a Python script.

4.5.4.2.8.1.1. Creating an empty Traffic Director Service

The following shows the creation of the very most basic empty TrafficDirector

>>> from dyn.tm.services.dsf import TrafficDirector
>>> td = TrafficDirector('TD_test_1', rulesets=[])
>>> #Now, lets look at the ID to make sure it was actually created.
>>> td.service_id
>>>u'w8WWsaqJicADC8OD1k_3GSFru7M'
>>> #service_id will be a long hash

4.5.4.2.8.1.2. Adding a Ruleset to your Traffic Director Service

The TrafficDirector service has a cascading style of adding sub objects where the child object is added to the parent by either and add_to_ function, or a create. This helps enforce that children objects do not become orphaned.

>>> #Continuing from the example above.
>>> from dyn.tm.services.dsf import DSFRuleset
>>> #Let's make a ruleset called 'The Rules' which always serves, and has no response_pools
>>> ruleset = DSFRuleset('The Rules', criteria_type='always', response_pools=[])
>>> #Now, lets add that ruleset to the Traffic Director instance from above.
>>> ruleset.create(td)
>>> #Now, Verify it was added. The 'rulesets' getter will return a list of rulesets attached to the td service instance.
>>> td.rulesets
>>>[<DSFRuleSet>: Label: The Rules, ID: gthPTkFOYUrJFymEknoHeezBeSQ]

4.5.4.2.8.1.3. Adding RecordSets, FailoverChains, RecordSets, and Records to your Traffic Director Service

Please see individual sections for instructions on how to actually do this, as with :class:`DSFRuleset`s, there is a cascading system:

TD <- Ruleset -> ResponsePool <- FailoverChain <- RecordSet <- Record

to ‘create’ each, the function looks like:
>>> ruleset.create(td)
>>> ruleset.add_response_pool(pool)
>>> pool.create(td)
>>> failoverchain.add_to_response_pool(pool)
>>> recordset.add_to_failover_chain(failoverchain)
>>> record.add_to_record_set(recordset)

4.5.4.2.8.1.4. Modifying Traffic Director Service Properties

You can modify such things as labels, ttl, etc for the TrafficDirector object. Note, that modifying these values will immediately publish them. This can be turned off as in the example below.

>>> #Continuing from the example above.
>>> #parameter updates will publish implicitly.
>>> td.label #check what the label is.
>>>u'TD_test_1'
>>> td.label='TD_test_2'
>>> td.label
>>>u'TD_test_2'
>>> #Now, say you don't want your update changes to be implicitly published. you can turn off implicit publishing for
>>> #the service level changes.
>>> #!!!WARNING!!!! changing the implicit publish flag ONLY disables implicit publishing for this Object,
>>> #not any of its children objects like Rulesets etc.
>>>
>>> td.label
>>>u'TD_test_2'
>>> td.implicitPublish = False
>>> td.label = 'TD_test_3'
>>> td.refresh() #pulls down fresh data from the system, as your td.label is now stale due to it not being published
>>> td.label
>>>u'TD_test_2'
>>> td.ttl = 299
>>> td.refresh()
>>> td.ttl
>>>300
>>> td.publish()
>>> td.ttl
>>>299
>>> td.label
>>>u'TD_Test_3'

4.5.4.2.8.1.5. Getting an Existing Traffic Director Service

The following example shows how to get an existing TrafficDirector from the dyn.tm System

>>> # Continuing from the previous example
>>> id = td.service_id
>>> gotTD = TrafficDirector(id)
>>> gotTD.label
>>>u'TD_Test_3'

What if you don’t know your service_id? But maybe you know the name…

>>> from dyn.tm.services.dsf import get_all_dsf_services
>>> get_all_dsf_services()
>>>[<TrafficDirector>: notme, ID: qzoiassV-quZ_jGh7jbn_PfYNxY,
...<TrafficDirector>: notmeeither, ID: qdE-zi4k7zEVhH6jWugVSbiIxdA,
...<TrafficDirector>: imtheone, ID: AwqcnhOZ6r1aCpIZFIj4mTwdd9Y]
>>> myTD = get_all_dsf_services()[2]
>>> myTD.label
>>>u'imtheone'

4.5.4.2.8.1.6. Adding/Deleting a Notifier to your Traffic Director Service

You can add notifiers to your Traffic Director service in the following ways:

Example 1:

>>> from dyn.tm.services.dsf import DSFNotifier
>>> notifier = DSFNotifier('deleteme', recipients=['youruser'])
>>> td.add_notifier(notifier1)
>>> td.refresh()
>>> td.notifiers
>>>[<DSFNotifier>: deleteme, ID: 8lJ9LUcP9sIuB8V58zsGWVu1Hys]
>>> #To delete:
>>> td.del_notifier(notifier1)
>>> td.refresh()
>>> td.notifiers
>>>[]

Example 2:

>>> #Notifiers can also be added at the creation time of the Notifier by passing in the service_id
>>> from dyn.tm.services.dsf import DSFNotifier
>>> notifier = DSFNotifier('deleteme', recipients=['youruser'], dsf_services=[td.service_id])
>>> td.refresh()
>>> td.notifiers
>>>[<DSFNotifier>: deleteme, ID: q-hZOVTn2Q_VCX1LFMSI-4LPTww]

4.5.4.2.8.1.7. Deleting Traffic Director Service

You can also delete your service in the following manner:

>>>td.delete() >>>td.refresh() >>>DynectGetError: detail: No service found.

4.5.4.2.8.1.8. Creating a fully populated Traffic Director Service

The following example shows how to create a new TrafficDirector on the dyn.tm System and how to edit some of the fields using the returned TrafficDirector object.

>>> #A fully populated service can achieved by creating a full chain and passing child objects into each parent object.
>>> #These objects are effectively constructor objects. In other words, they will be useless for CRUD operations, except for
>>> #The TrafficDirector object. There are other means for achieving CRUD operations as you will see.
>>>
>>> from dyn.tm.services.dsf import *
>>> from dyn.tm.zones import Node
>>>
>>> #Lets start with our objects that are actually created when the command is executed.
>>>
>>> #First, lets make our Monitor. we pass this in to the recordset later. This monitor is created at execution time.
>>> monitor = DSFMonitor('MonLabel', 'HTTP', 1, 60, 1, port=8080)
>>>
>>> #Second, lets make a new Notifier -- this is optional. We'll assume you have a contact named 'contactname'
>>> notifier = DSFNotifier('Notifier', recipients=['contactname'])
>>>
>>>
>>> #Next lets make our A Record prototype:
>>> a_rec = DSFARecord('1.1.1.1', ttl=60, label='RecordLabel')
>>>
>>> #Next, lets create the record_set. Note how we pass in the a_rec A Record Object, and the monitor_id
>>> record_set = DSFRecordSet('A', label='RSLabel', dsf_monitor_id = monitor.dsf_monitor_id,records=[a_rec])
>>>
>>> #Next, lets create the failover chain Note how we pass in the record_set RecordSet Object
>>> failover_chain = DSFFailoverChain(label='FCLabel', record_sets=[record_set])
>>>
>>> #Next, lets create the response pool Note how we pass in the failover_chain Failover Chain Object
>>> rp = DSFResponsePool(label='RPLabel', rs_chains=[failover_chain])
>>> criteria = {'geoip': {'country': ['US']}}
>>>
>>> #Next, lets create the ruleset Note how we pass in the rp Response Pool Object
>>> ruleset = DSFRuleset(label='RSLabel', criteria_type='geoip',
...                      criteria=criteria, response_pools=[rp])
>>>
>>> #Now, lets create a Node object. This is used for attaching the service to a Node (or zone)
>>> node = Node('example.com',fqdn = 'example.com.')
>>>
>>> #Finally, we pass all of this in. upon command execution the service will have been created.
>>>
>>> dsf = TrafficDirector('Test_Service', rulesets=[ruleset], nodes=[node], notifiers=[notifier])

Now that you have created your service in one fell swoop, there are a few things you must know:

Prototype objects like your DSFARecord, DSFRecordSet are just that, prototypes. You can’t perform CRUD operations on them. This goes for any child object where you pass in prototypes. See examples below:

>>> #Trying to access a prototype
>>> a_rec.address='1.2.3.4'
>>>DynectUpdateError: record_update: No service found.
>>> #Instead, do this:
>>> dsf.records
>>> [<ARecord>: 1.1.1.1]
>>> dsf.records[0].address='1.2.3.4'
>>> dsf.records[0].address
>>> u'1.2.3.4'

4.5.4.2.8.1.9. Traffic Director SDK Caveats

  • Creating a fully populated service with prototypes leaves the prototypes unusable. CRUD capabilities can only be achieved by accessing data within the TrafficDirector object. Accessors are records, record_sets, failover_chains, response_pools, rulesets
  • Accessors like in the previous bullet point only work if the object is fully linked to the service. In other words, you can have a full response_pool, but if it does not belong to a ruleset, then it will not show up. To list all objects under the service, including orphands you must use all_records, all_record_sets, all_failover_chains, all_response_pools, all_rulesets
  • Some records, record_sets, failover_chains, response_pools, rulesets will appear multiple times. This is because these record trees are built from the ruleset, and if one response pool belongs to multiple Rulesets, then its children will appear as many times as is exists as a ruleset member.
  • refresh() is your friend. When modifying child objects from a parent sometimes the parent doesn’t know about the changes. If you do a refresh() on the TrafficDirector object it will pull down the latest data from the Dynect System.
  • publish() is run on the TrafficDirector as a whole, even when run from a child object.
  • implicitPublish is non cascading. It is locally bound to the specific object, or child object.