Dyn’s easy-to-use GUI is the most commonly used interface for managing DNS zones for managed/outsourced users, but did you know that we have an API that lets you automate your everyday processes?
Our API gives you the flexibility to tailor our platform to your unique use case. Say for instance, you’ve got a few hundred zones in our system and every one of them has a node that needs to be updated with a new A-record. Wouldn’t it be sweet if you had a script that could just pop into DynECT and switch out that node on every zone?
Believe it or not, our API is super simple to manipulate for your unique needs.
All of our APIs are built to support a vast array of common (and some not so common) programming languages and runtimes. Of course, most modern programming languages are similar enough in their scope and intended functionality that following the workflow of any bit of code will be a fairly straightforward and familiar practice after familiarizing one’s self with the basic design of an API call.
The languages utilized by our APIs include, but are certainly not limited to:
- Ruby on Rails
The basic mode of operation within the DNS API involves a few key components, regardless of the protocol you’re using.
Before any interaction can take place within DynECT, a session must first be established. Logging in with REST, SOAP, or XML-RPC will establish this session and yield a Token. The Token will be used with every API call to validate the authenticity of a request.
This is the point in any script where it is always handy to have a way of creating an object from the Token so it can be referenced throughout the session without having to keep putting the token in over and over again.
This is where the magic happens. All of the protocols have a list of available function calls that can be used to create, modify, or delete records, services, nodes or zones from the DynECT account that the session user is logged into.
Each request made in the API returns a Job ID; zone change requests are queued within a Changeset. Changesets allow for a zone configuration to be finalized before it goes live and can be reviewed or removed at anytime. Job IDs allow a user to check on the status of a request or fetch the response of a previously completed request. Both Changesets and Job IDs are only valid for the duration of a session.
When a user is ready to make his or her Changesets live, they just need to call the respective publish command for the specific protocol they are working with. All pending Changesets for a zone go live when the publish request is made.
While an unused session can and will eventually timeout, it is always recommended to log out from one’s session when scripts are complete.
That, in a nutshell, is the basic mode of operation of a DynECT Managed DNS API script. If you’ve got Lite or the full version already, you’re ready to start using the API today! All of the API calls are in the DNS Knowledgebase for your reference.
Not using us yet? Check out DynECT Managed DNS Lite to get started, but if your web speed needs are a bit more (think Active Failover, Traffic Management, and Geo Traffic Management), connect with one of our friendly Enterprise Sales Representatives today by filling out that nice form below.