Suggested API improvements

2/16/2023 11:19

In developing an integration for an ACME challenge, there was several issues that highlighted improvement opportunities for the dynadot APIs.
Suggested API improvements:
1. Providing the API token via a GET URL Parameter is considered a poor security practice, as that has a tendency to show up in server logs. Case in point, I noticed this while testing/developing an ACME script plugin and found that the full URL with the token was being logged when client debugging was turned on. Suggested update: accept the token in an URL parameter OR a header, such as the common: “Authorization: Bearer {TOKEN}”, e.g. “Authorization: Bearer AbCdEf123456”. Accepting it in either location will allow us to transition to a security best practice without breaking current users already using the URL parameter.

2. The response values from “get_dns” should provide appropriate input values for “set_dns2”. Ensure that the case sensitive fields match the case for both api commands. For instance, currently from “get_dns” I receive: "RecordType": "Forward", but “Forward” gets rejected by “set_dns2” for main_record_type0/sub_record_type0, and must be changed to all lowercase “forward”.

3. Accept the output of “get_dns” as the input for “set_dns2”. There should be an option to pass the JSON/XML output received from “get_dns” as a POST body to “set_dns2” (or a new “set_dns3”). This would allow retrieving the JSON, updating it with the necessary changes, and POST-ing that back to perform the update rather than having to manipulate that into the URL params that all have very different names than the JSON/XML fields.

4. For “set_dns2” with “add_dns_to_current_setting = 1”, do not append duplicates. If the combination of main_record_type0, main_record0, and main_recordx0, match an existing record, it should not be duplicated. Please note that it would need to match all three values, as TXT records in particular may be duplicated with multiple values (but there’s no need for a duplicate TXT entry with the same record and value).

5. “set_dns2” with “add_dns_to_current_setting = 1”, does not allow appending ONLY a sub_record. An error is returned stating that a main record is required. If you only have a sub_record to append and not a main_record, there’s currently no way to perform that action in the append mode (I could provide an existing main record plus the sub record, but then that main record is duplicated (see suggestion #4). This “add” or append mode should be updated so that it can append only a sub_record, i.e. the validation should require a main_record OR a sub_record. Providing one OR the other OR both should be accepted and appended.

6. Add a “remove_dns_record”, which accepts domain and either a main record or a sub record (main_record_type0, main_record0, main_recordx0 ) OR ( subdomain0, sub_record_type0, sub_record0, sub_recordx0). This should look for an exact match of those fields and remove that single entry (the opposite action of the append with “set_dns2 / add_dns_to_current_setting = 1”

Reply QuoteLike

[quote]d_h_st_peters_us says: In developing an integration for an ACME challenge, there was several issues that highlighted improvement opportunities for the dynadot APIs.
Suggested API improvements:
1.	Providing the API token via a GET URL Parameter is considered a poor security practice, as that has a tendency to show up in server logs.  Case in point, I noticed this while testing/developing an ACME script plugin and found that the full URL with the token was being logged when client debugging was turned on.  Suggested update: accept the token in an URL parameter OR a header, such as the common: “Authorization: Bearer {TOKEN}”, e.g. “Authorization: Bearer AbCdEf123456”.  Accepting it in either location will allow us to transition to a security best practice without breaking current users already using the URL parameter.

2.	The response values from “get_dns” should provide appropriate input values for “set_dns2”.  Ensure that the case sensitive fields match the case for both api commands.  For instance, currently from “get_dns” I receive: "RecordType": "Forward", but “Forward” gets rejected by “set_dns2” for main_record_type0/sub_record_type0, and must be changed to all lowercase “forward”.

3.	Accept the output of “get_dns” as the input for “set_dns2”.  There should be an option to pass the JSON/XML output received from “get_dns” as a POST body to “set_dns2” (or a new “set_dns3”).  This would allow retrieving the JSON, updating it with the necessary changes, and POST-ing that back to perform the update rather than having to manipulate that into the URL params that all have very different names than the JSON/XML fields.

4.	For “set_dns2” with “add_dns_to_current_setting = 1”, do not append duplicates.  If the combination of main_record_type0, main_record0, and main_recordx0, match an existing record, it should not be duplicated.  Please note that it would need to match all three values, as TXT records in particular may be duplicated with multiple values (but there’s no need for a duplicate TXT entry with the same record and value).

5.	“set_dns2” with “add_dns_to_current_setting = 1”, does not allow appending ONLY a sub_record.  An error is returned stating that a main record is required.  If you only have a sub_record to append and not a main_record, there’s currently no way to perform that action in the append mode (I could provide an existing main record plus the sub record, but then that main record is duplicated (see suggestion #4).  This “add” or append mode should be updated so that it can append only a sub_record, i.e. the validation should require a main_record OR a sub_record.  Providing one OR the other OR both should be accepted and appended.

6.	Add a “remove_dns_record”, which accepts domain and either a main record or a sub record (main_record_type0, main_record0, main_recordx0 ) OR ( subdomain0, sub_record_type0, sub_record0, sub_recordx0).  This should look for an exact match of those fields and remove that single entry (the opposite action of the append with “set_dns2 / add_dns_to_current_setting = 1”[/quote]

In developing an integration for an ACME challenge, there was several issues that highlighted improvement opportunities for the dynadot APIs.
Suggested API improvements:
1.	Providing the API token via a GET URL Parameter is considered a poor security practice, as that has a tendency to show up in server logs.  Case in point, I noticed this while testing/developing an ACME script plugin and found that the full URL with the token was being logged when client debugging was turned on.  Suggested update: accept the token in an URL parameter OR a header, such as the common: “Authorization: Bearer {TOKEN}”, e.g. “Authorization: Bearer AbCdEf123456”.  Accepting it in either location will allow us to transition to a security best practice without breaking current users already using the URL parameter.

2.	The response values from “get_dns” should provide appropriate input values for “set_dns2”.  Ensure that the case sensitive fields match the case for both api commands.  For instance, currently from “get_dns” I receive: "RecordType": "Forward", but “Forward” gets rejected by “set_dns2” for main_record_type0/sub_record_type0, and must be changed to all lowercase “forward”.

3.	Accept the output of “get_dns” as the input for “set_dns2”.  There should be an option to pass the JSON/XML output received from “get_dns” as a POST body to “set_dns2” (or a new “set_dns3”).  This would allow retrieving the JSON, updating it with the necessary changes, and POST-ing that back to perform the update rather than having to manipulate that into the URL params that all have very different names than the JSON/XML fields.

4.	For “set_dns2” with “add_dns_to_current_setting = 1”, do not append duplicates.  If the combination of main_record_type0, main_record0, and main_recordx0, match an existing record, it should not be duplicated.  Please note that it would need to match all three values, as TXT records in particular may be duplicated with multiple values (but there’s no need for a duplicate TXT entry with the same record and value).

5.	“set_dns2” with “add_dns_to_current_setting = 1”, does not allow appending ONLY a sub_record.  An error is returned stating that a main record is required.  If you only have a sub_record to append and not a main_record, there’s currently no way to perform that action in the append mode (I could provide an existing main record plus the sub record, but then that main record is duplicated (see suggestion #4).  This “add” or append mode should be updated so that it can append only a sub_record, i.e. the validation should require a main_record OR a sub_record.  Providing one OR the other OR both should be accepted and appended.

6.	Add a “remove_dns_record”, which accepts domain and either a main record or a sub record (main_record_type0, main_record0, main_recordx0 ) OR ( subdomain0, sub_record_type0, sub_record0, sub_recordx0).  This should look for an exact match of those fields and remove that single entry (the opposite action of the append with “set_dns2 / add_dns_to_current_setting = 1”

Posted By dndt_

3/21/2023 10:13

.

Reply QuoteLike

Posted By teamdynadot

5/18/2023 09:41

Hello,

Thanks for taking the time to bring this to our attention. We will use the feedback to make us better. We also would like to recommend you submit a feature request from the Support dropdown menu on the right side of the website. Our management team will take a further look and handle the request for you from there:
https://www.dynadot.com/

Best regards,
Dynadot Support Team

Reply QuoteLike

Forum