Update not working

21

Good to know. Thanks.

22

A close inspection of my initial post shows that there is only one content-type header (line 3). It is only when -v is used that one sees two instances. So where is that second instance coming from? Should I have not put it in as a header line?

23

To the best of my knowledge, new tokens are valid instantly. So, there’s something wrong with your command and I can only guess, what it might be. It’s a fairly common mistake to send the token ID (a UUIDv4) instead of the token value (some random character string). You may want to double check that.

That is not something I can reproduce with my build of curl (also version 8.19.0). The API needs the Content-Type: application/json header, so you need it in your curl command.

I could neither reproduce this error message from the API nor find it in the source code. Without or with a malformed Authorization header, I get Authentication credentials were not provided.. With an invalid token value I get Invalid token..
I don’t know if this is any help.

24

OK, I got my API_TOKEN test working. I removed the curly braces.
Now when I run the original command:

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”
         ]
       }
     ]’

I get the following:
[{“non_field_errors”:[“Another RRset with the same subdomain and type exists for this domain. (Try modifying it.)”]}]%

This is happening because I have already inserted the record manually.
My understanding was that, with this method of updating, the required RRset would be created as necessary, otherwise just overwritten. The above text suggests otherwise. I’ll try deleting the record, and then doing the update again.

In any case, the errors I was getting yesterday:
{“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.”}
no longer happen. Wore out another bug. Sometimes I have to be satisfied with success.

25

Having deleted the manually-inserted DKIM record, when I run the above curl command, I get:
[{“non_field_errors”:[“Data for TXT records must be given using quotation marks.”]}]%

I do not understand this, since the entire -d argument is enclosed in single quotes.

26

You may want to read the documentation, specifically Modifying an RRset.

Three additional remarks:

  • Your post still contains curly quotes. I.e. you are still not showing your exact command as this is not valid shell syntax.
  • Your multiline curl command still lacks the required \ to escape the newlines. Again, not valid shell syntax.
  • The -X POST parameter is redundant in recent versions of curl because the -d option implies a POST request. (However -X PUT or -X PATCH would still be required.)
27

Read my first answer to this thread again. Enclose the value of the TXT record with escaped ", i.e. "records":["\"v=DKIM1; …\""]

28

My keyboard doesn’t have have curly quotes, and neither does my terminal. I know when I paste into a word processor, the word processor “helpfully” translates to curly quotes. Vim doesn’t do that. Nevertheless, I tried escaping the “ in the [ ] for records. I got this:
{“detail”:“JSON parse error - Expecting value: line 7 column 12 (char 143)”}%

I believe the backslash to escape newlines is not necessary within quotes, assuming the recipient has no problem with the newlines. I tried it nevertheless, and got:
{“detail”:“JSON parse error - Expecting value: line 1 column 3 (char 2)”}%

I’d paste the command, but the backslashes don’t get shown here.

If I put ‘echo’ in front of the ‘curl’ command, I get this:

curl -X POST https://desec.io/api/v1/domains/azadian.ch/rrsets/ -H Authorization: Token 9HRLjRk2jjQiKFutiSznURFKDZVr -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"
         ]
       }
     ]
29

As for modifying an RRset, the DKIM ID that my ISP gives me includes a date, so normally the record would be new.

30

You need a better editor for code :wink:! And why are you pasting to a word processor at all?

This may also be an OS feature which you might be able to turn off.

I’m guessing that you tried "records":[\"v=DKIM1; …\"]? If so, no! You need the outer quotes unescaped for the JSON string and the escaped inner quotes for the TXT value, just like my example. Do a GET request on a TXT RRset to see what it should look like.

31

I don’t use a word processor, I use vim. When I paste into gedit, it does the curly stuff.
I put in the “unnecessary” escaped double-quotes as suggested, and it worked. It looks absolutely crazy to me, but I won’t argue with success. Thank you for your help.

32

See RFC 1035 sections 3.3.14 TXT RDATA format and 5.1, <character-string>:

TXT-DATA One or more <character-string>s.

<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ".

Thus the interior double quotes are part of the TXT value, because the DKIM record value contains spaces. And because JSON strings also use double quotes the interior ones need to be escaped.

33

Hi @nhazadian,

please be aware that you posted another token secret. I took the liberty of invalidating it, so you’ll have to create a new one.

34

Thanks, I missed that one entirely.