gc948486cbc56b8
By:
gc948486cbc56b8

DKIM field only 512 chars; need the instructions for using tokens to fill the field

December 22, 2017 853 views
DNS CentOS

I've attempted to fill the TXT field in my DNS for the DKIM key. I'm getting a message that the field can only be 512 characters. These days you need a 2048 key. (1024 uses to be good enough) Anyway, there is a procedure to use tokens to fill in DNS fields in order to get around the problem. I was given this once by tech support and neglected to save it. I found a link for web page for the procedure, but apparently Sammy the Whale ate the page.

So I need the procedure to file a TXT field in DNS using a token. My recollection is you used curl from your server to do this, or maybe your PC.

Log In to Comment
2 Answers
gc948486cbc56b8 December 23, 2017

I spent a while hacking on this and figured out the tricks. Hopefully this will save the next person an hour or two of head banging.

First, get a token from Digital Ocean. Go to your control panel. Click on API. Turns out my old token was still there. Anyway, generate a new token. You need to save this on your local PC, not your droplet. (Technically save it where you will be running curl, which probably is your local PC.) You can always go back to the control panel and regenerate the token by clicking on edit and following instructions.

The instructions to edit a DNS are found here:
DNS API instructions

Note there is a curl example at the right side of the page. However it is not for entering the dkim parameter. What I did is read the instructions and changed the example for entering the dkim parameter. But there is a catch. The p parameter of the dkim public will run over several lines. If you used opendkim-genkey, there will be continuations and such. In theory you could use them as is, but I couldn't get the api to work. What I suggest is using an editor (vi nano etc) to create a file containing the curl command and run it using sh. I called mine feed_dkim. Here is a sanitized version of the file. (fake key, domain, etc.) What you want to make sure is your quoted fields look like mine, that is no nested quotes. The output of opendkim-genkey will add quotes that you don't need.

curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer tokengoeshere" -d '{"type":"TXT","name":"default._domainkey","data":"v=DKIM1; k=rsa; s=email; p=nPnay721k2ApKmCXeg9DZgcZE4yr5Vw8P2nd3NeLSHYEuflTN0osXODUmFLqSxHnPnay721k2ApKmCXeg9DZgcZE4yr5Vw8P2nd3NeLSHYEuflTN0osXODUmFLqSxHnPnay721k2ApKmCXeg9DZgcZE4yr5Vw8P2nd3NeLSHYEuflTN0osXODUmFLqSxH","priority":null,"port":null,"ttl":1800,"weight":null,"flags":null,"tag":null}' "https://api.digitalocean.com/v2/domains/mydomain.com/records"

Things to change:
1) Replace tokengoeshere with your token
2)The field after "name" is your key selector. I'm using tables, so I left it as default. (This depends on your opendkim setup.)
3) The field after "data" is your key. The p field is the long one. If you see slashes in your generated key, those are continuations. You need to delete them, basically getting the p field to be one long string
4) Change mydomain.com to whatever your domain is.

I used vi to create the feed_dkim file. You should verify the file is one long line. Use the up/down arrow keys. If you have multiple lines, control J will join them.

On your PC:
sh feed_dkim

and hope for the best. There will be an error message if it bombs. You can go to your control panel and look at the results.

Since this is a DNS field, you will have to wait for DNS propagation. Once the field propagates, use this website to test your dkim.
dkim validator

Reply
umask February 21, 2018

Does not work :-(

curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer MY_TOKEN_HERE" -d '{"type":"TXT","name":"abcd-efgh-2211775533-4455._domainkey","data":"v=DKIM1; r=postmaster; g=*; k=rsa; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","priority":null,"port":null,"ttl":3600,"weight":null,"flags":null,"tag":null}' "https://api.digitalocean.com/v2/domains/mydomain.tld/records"

Response is:

{"id":"unprocessable_entity","message":"Data is too long (maximum is 512 characters)"}

(as in DNS Manager in web browser).

I'm trying to move from ISC BIND (which is working fine with the same public keys length).

Reply
  • gc948486cbc56b8 February 22, 2018

    I did this for three domains and still have the shell scripts. Your basic format looks OK.

    Did you set this up as a script? I made mine in vi as one long line.

    I just ran my script again and it works fine. Since there is no limitation on the number of TXT fields in the domain record, you can run the script, create a duplicate DKIM field, then delete it.

    My response has a number for the ID field. I will post a piece of the return with the ID as xxxx.

    {"domain_record":{"id":xxxx,"type":"TXT","name":"default._domainkey

    with the rest of the reply being the data I uploaded to DNS.

    Now I took your sample line and set it up with my token, and indeed the field is too long. I'm using a 2048 bit key. So it looks like I phrased this post incorrectly. (Bits, not chars.) The data field is limited to 512 chars. It seems a 2048 bit key will upload with this method. My data field is about 420 characters. It will not upload with a cut and paste using any browser I have. I do have to use the token.

    Are you using a 4096 bit key? If so, use 2048 for now. I believe Digital Ocean will need to change their code for larger fields. Today, 2048 bits is acceptable. Remember this key isn't for encryption. It is just for identity and proof the message wasn't altered. I have no doubt Google will make us go to 4096 someday.

Have another answer? Share your knowledge.

Related Questions