Update not working

curl -X POST “https://desec.io/api/v1/domains/azadian.ch/rrsets/”
-H “Authorization: Token $API_TOKEN”
-H “Content-Type: application/json”
-d ‘[
{
“subname”: “azadianch-20260430._domainkey”,
“type”: “TXT”,
“ttl”: 3600,
“records”: [
“v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD3Ejp2QcQHcAhirtQklloDqtyPX9kOasyicCKPRYXs65eEISQ6L/7qaga/qHK88rOuUBXnhHqBB1Zalw/flaVHmS+wmC82om4kJDlwwParktLTj0mK79j/hgUUb5V+JyXHunbzZ5Sm7qtzpNOSlN+NRqnsgt6qwC5b23plQE/1swIDAQAB”
]
}
]’
{“result”: null, “id”: null, “error”: {“code”: 5, “message”: “TypeError: list indices must be integers or slices, not str”}}
{“detail”:“Invalid token header. No credentials provided.”}

What am I doing wrong?

Did you forget to escape the newlines in your curl command line?

Otherwise I’m not sure. Maybe you need to include escaped quotes in the value of the TXT record?

I.e. "\"v=DKIM1; …\""

At least that is what I get when doing a GET on the RRsets of a domain when there are TXT records.

If that turns out to be the issue then the error message seems a bit misleading.

I’m also unsure about the extra whitespace in the form of line feeds in your TXT value.

Not sure about that one either. The message seems unrelated to the previous error message. Is your API token valid, i.e. is the value of API_TOKEN set correctly? You could test with something like:

curl --url 'https://desec.io/api/v1/domains/azadian.ch/rrsets/' \
-H "Authorization: Token $API_TOKEN"

HTH
fiwswe

= curl --url ‘https://desec.io/api/v1/domains/azadian.ch/rrsets/’
-H “Authorization: Token $API_TOKEN”
{“result”: null, “id”: null, “error”: {“code”: 5, “message”: “JSONException: JSON not decodable”}}
{“non_field_errors”:[“No data provided”]}

A post was split to a new topic: Update request causes 404 error

@nhazadian, are you sure this output really comes from deSEC? I’m not aware that we send any responses containing a “result” field. It looks somewhat like you may be reformatting the output using your shell, and that causes the error. Is that possible?

Stay secure,
Peter

When I run curl with -v, here’s the critical last part of the output:

  • Established connection to desec.io (2a01:4f8:10a:1044:deec:642:ac10:80 port 443) from 2001:1686:44d:8000:dd6e:107d:d36e:9893 port 36644
  • using HTTP/2
  • [HTTP/2] [1] OPENED stream for https://desec.io/api/v1/domains/azadian.ch/rrsets/
  • [HTTP/2] [1] [:method: POST]
  • [HTTP/2] [1] [:scheme: https]
  • [HTTP/2] [1] [:authority: desec.io]
  • [HTTP/2] [1] [:path: /api/v1/domains/azadian.ch/rrsets/]
  • [HTTP/2] [1] [user-agent: curl/8.19.0]
  • [HTTP/2] [1] [accept-encoding: deflate, gzip, br, zstd]
  • [HTTP/2] [1] [content-type: application/json]
  • [HTTP/2] [1] [accept: application/json]
  • [HTTP/2] [1] [authorization: Token xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
  • [HTTP/2] [1] [content-type: application/json]
  • [HTTP/2] [1] [content-length: 406]

POST /api/v1/domains/azadian.ch/rrsets/ HTTP/2
Host: desec.io
User-Agent: curl/8.19.0
Accept-Encoding: deflate, gzip, br, zstd
Content-Type: application/json
Accept: application/json
Authorization: Token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json
Content-Length: 406

  • upload completely sent off: 406 bytes
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    < HTTP/2 415
    < server: nginx
    < date: Sun, 03 May 2026 11:41:16 GMT
    < content-type: application/json
    < content-length: 86
    < allow: GET, POST, PUT, PATCH, HEAD, OPTIONS
    < vary: origin
    < strict-transport-security: max-age=31536000; includeSubDomains; preload
    <
  • Connection #1 to host desec.io:443 left intact
    {“detail”:“Unsupported media type “application/json, application/json” in request.”}

You’re sending the Content-Type header twice, which is not allowed.

It’s really hard to help you debug like this, as we don’t know your original curl commands. Please send full commands along with any output.

Also, make sure to mask your API tokens. I’ve used the one you posted above to log out from your account (so it’s now invalid).

Stay secure,
Peter

Good point with masking the API tokens; I’ve edited accordingly.
I started this thread with my one original curl command. The -v output is from that command.

That seems very unlikely, as the error message in the response bodies are different.

The best way to debug is to copy command and output together from your terminal. Make sure that nothing is changed (not even the style of double quotes – they seem changed in your first post). We need a literal 1:1 copy of what happened.

I’ll stop responding here until that’s provided (no offense; I just can’t help you any further).

Stay secure,
Peter

My original post was an exact copy of the input and output together from my terminal. I do not know why the result with -v was different. Should I provide screenshots?

Now it appears the only response I get is “Invalid token.” I don’t know why that would be.

My AI (which recommended you) thinks that the problem is a bug in your software. I’m not so sure.

My ISP has offered free DNS, with the added advantage of maintaining the DKIM entry for me. I declined since I wanted to support your excellent free service. But if I don’t get some help with this soon, I’ll have to look elsewhere. (No offense, I’ve just got to get my email working.)

See Update not working - #7 by peter.

This is the community forum, not customer support.

Stay secure,
Peter

1 Like

Well, Peter, as YOU wrote: “Community support is essential for spreading the use of deSEC’s secure DNS service.”
Now if I have to ask my question in an email to support, I can do that, no problem. Just let me know.
It would be helpful to know how I can test my token.

If you want to test your token, I recommend using a simple API call. Something like listing domains:

curl https://desec.io/api/v1/domains/ \
    --header "Authorization: Token {secret}"

This will either return status code 200 (and the list of domains in your account) or status code 401. The latter means that the token is not valid.
However, I believe token validity is among the first things that the API checks for a request. Since you already got a “Invalid token” response somewhere else, you’ll get the same for this simple test unless something is very wrong.
This means, you’ll have to create a new token and use that.

But this whole thread strikes me as a bit of a XY problem. You posted a curl command that does not work. But what do you actually want to achieve? Get the curl command right? Or set up some DNS records? In the latter case, you may want to look into Tools implementing deSEC for some community tools that provide a somewhat simplified abstraction layer for the API.

Thanks for the tip. Here’s what I’m getting:

= curl https://desec.io/api/v1/domains/ \
–header “Authorization: Token {$API_TOKEN}”
{“detail”:“Invalid token.”}%
= echo $?
0

Color me confused.

I have a script that lets me add a DKIM record when my ISP notifies me that there is a new one to be added. The curl command I posted is what the script runs to do the update. When I run it now, I get “Invalid token.”, whereas yesterday the identical script produced a completely different answer. Looks like I’ve been blacklisted.

I’m not aware of deSEC doing that. The API may rate limit you, but in that case you’ll get a response that clearly indicates this.

Are you still using the same token that you posted in Update not working - #6 by nhazadian? Peter invalidated that to protect your account. Or did you create a new one in the mean time?

A link to this script might be helpful to better understand what you are doing here.

deSEC enforces its terms of use in two ways:

  1. Rate limits on requests; requests are answered with an appropriate error message and an estimation when the next successful request can be made (§1 ToU).
  2. Closing accounts and disconnecting domains for criminal activity, including denylisting abused IP ranges (§5 ToU).

Neither is the case here. Your token seems to have been deactivated because you posted it publicly - but it’s supposed to be private as it can control your account.

Nils

Yes, my token was publicized for some minutes before I corrected that. That was my mistake, and deactivation was arguably justified. I say arguably because only my domain was impacted by the breach. The publication put only my domain in danger, and, given that it was public only for some minutes, a simple warning to replace the token with a new one would perhaps have been more appropriate.
Less justifiable is that I was not notified of the deactivation, either in deSEC or by email. After all, my dyndns script also uses that token, and if my IP gets changed, my email server can neither receive nor send email. IMHO, any deactivation should at the very least automatically issue a notification in deSEC.

Discourse keeps a history of all post edits, so the token value can still be viewed. Click the edit indicator in the upper right corner of your post to check for yourself.

I like the idea of email notifications for token creation, deactivation, and generally all security relevant actions on the account.

deSEC is a charitable organization with limited resources, so we don’t know if and when this makes it to the top of our priority list. However, if you’d submit a pull request with the appropriate code changes, this change can probably land soon as deSEC only needs to review.

Thanks,

Nils

I got myself a shiny new token. After about 90 minutes, I’m still getting “Invalid token.” in response to the query for my domains.
As for my script, it’s a simple affair which simply take a couple strings from the command line and uses them to assemble the curl command that I presented at the start of this thread. The intent is to add a new DKIM record that my ISP has specified.