1. Why is there a 5-second response requirement on API queries?
API queries/commands are asynchronous, that is more than one can run at the same time. However, there are some large jobs which may take more than 5 seconds to respond.
2. How much data can I retrieve when I run a QPS query using the API?
There is a limit to the amount of data the Managed DNS system will retain for a given feature. Here are the lengths of time each feature retains its data:
Host — 3 weeks
Zone — 3 months
Record Type — 18 months
Total QPS — 36 months
Additionally, you can access an example of how to make QPSReport queries at the following Github location: https://github.com/dyninc-cs/DNS-Usage_Details
3. Do I need to be an expert programmer to use the API?
You do need to have an understanding of scripting and programming, but you do not need to be an expert. We have included some examples to assist you in managing your Managed DNS account using the API. The examples are not comprehensive, however, you can use them to understand the required syntax for including API commands into your scripts and programs.
4. What reporting options do you have for DNS data?
Here are the items you can retrieve using the API resources/commands.
NOTE: All report data are delivered in CSV format.
QPS Report — Generates a report that contains the Queries per identified time period for specific time intervals.
RTTM Log Report — Generates a report for any changes to an existing Real Time Traffic Management service.
RTTM RRSet Report — Generates a report of the regional response sets for a Real Time Traffic Management service based on a given point in time.
DNSSEC Timeline Report — Generates a report of events the DNSSEC service has performed, or events scheduled to be performed.
Zone Note Report — Generates a report that contains the Zone Notes for the zone indicated.
User Permission Report — Generates a report containing the identified user’s permissions.
Check Permission Report — Generates a report of user permissions based on the user requesting the report.
5. How do I find the “record_id” for the MX Record type?
For the MX Record API REST resources, the URI is in this format: /REST/MXRecord/zone/fqdn/record_id.
The record_id is a unique identifier for this MX Record for this API session. Doing a GET call for this record, you would get a response file containing something similar to this: ‘/REST/MXRecord/myzonename.com/hostname.myzonename.com/8446525‘
The record_id in this response URI is 8446525.
6. There are 4 NS Records that I don’t recognize and did not add to my primary zones. Where did they come from and why can’t I delete them?
When your account is created, you are assigned to one of several Managed DNS name server pools.
The NS Records have the format ns1.pxx.dynect.net., where xx is a 2-digit number representing the pool number where your account is assigned. These Name Server records (NS) are automatically added to all primary zones in your account.
They are the Name Server records that we use to help manage your DNS.
7. I am planning on making large scale changes to my account using the API. What is the best way to accomplish this task?
Our Concierge Team is well trained to help you effectively make large scale changes to your account while utilizing our API as efficiently as possible. You can reach them by contacting concierge@dyn.com.
8. I am making changes to the Traffic Director Notifiers and getting a permissions error, why is that?
In order to Add, Edit, or Delete a DSF Notifier, you must have DSFNotifier and DSFUpdate permissions on your Managed DNS account. Check the permissions of your account using the instructions on the Manage User Permissions help page.
9. Is there a request-rate limit?
Yes. Dyn’s Managed DNS API has a set request-rate limit to prevent abuse of the service. Please see Managed DNS API Rate Limit for more information.
10. Can I open multiple sessions?
Yes, but it is recommended not to work on the same resource (e.g the same hostname or instance of a service) from multiple sessions. Operating on the same resource from more than one session at the same time may cause unexpected behavior, such as unintentional service changes or the inability to propagate new zone changes.