Ever wondered how you deal with long DKIM records? Because if you think you can just stick that bad boy in a text field, chances are that is going to fail. Horribly. There is an RFC (Request for Comments – or internet adopted standard) that says that TXT fields within a DNS zone need to be under 254 chars.. If they are not they will either be kicked out again, rejected, or worse still accepted and then fail to propagate and throwing a properly large spanner in the works.

Thankfully the internet is here to help.

There is another RFC that lays out a means and structure to put in these crazy long strings into TXT fields, and still have them work. Who knew – right?

So – RFC suggests splitting it up. Sure – it all goes in the same record, but it is handled as different records, and chunked back together by the application at the other end. It complies by the rules, yet manages to work around them.

The long and the short of it is the following:

“v=DKIM1; k=rsa; p=MIIBIjANBgksdfsdfsdfsdfsdfsdfsdf/” “kldfgnmansnausdnffNNNnmnsdnasd” “jnakakksnnfuwuerhfhHQR”

…where you do not need to cut it off at the 254th char – you can just pick neat places all the way through to the end.

If you are having issues sleeping the full article can be found over on the http://www.opendkim.org/opendkim-README – with particular reference to LARGE KEYS.

For the sake of completeness – this is below for completeness:

LARGE KEYS
==========

If you wish to use a large key in DNS, there are some limitations of which
you should be aware. A TXT record in the DNS consists of a series of
strings each of which don’t exceed 255 bytes. This is a result of the
fact that each string is preceded by a length byte (which, of course,
can’t exceed 255). Furthermore, some DNS implementations don’t allow
packets larger than 512 bytes. Some RSA keys will exceed the 255 byte
limit once encoded with base64, so some special formatting must be
used to make such a record fit. Failing to do so can cause an incomplete
record to be published or, worse, the nameserver to refuse to serve the
record or even the entire zone.

In the case of the BIND nameserver, there are two syntax rules one can use
to make a large record fit within these boundaries:

1) TXT substrings

Instead of a record like:

recname IN TXT “foobarbazblivitalphabravocharliedelta…zulu”

…one can also do:

recname IN TXT “foobar” “baz” “blivit” “alpha” … “zulu”

(The “…” is mean to indicate continuation and is not a literal set of
three “.” characters.)

You simply have to break up the large record into smaller strings such
that no string exceeds 255 bytes. DKIM implementations will
reassemble TXT records broken down this way into the full original
single string before processing them.

2) Line continuations

It can be difficult for some to edit very long lines of text.
It’s therefore desirable to have a mechanism to break very long
TXT records down so that they fit nicely within an editor window.
In BIND, this is done by enclosing the wrapped lines within
parentheses. Continuing with the example above, this:

recname IN TXT “foobar” “baz” “blivit” “alpha” … “zulu”

…can also be expressed as:

recname IN TXT ( “foobar” “baz” “blivit” “alpha”
“bravo” “charlie” “delta” “echo”
…
“yankee” “zulu” )

So using these two techniques, a very large public key could be encoded
in a DNS zone file as follows:

recname IN TXT ( “v=DKIM1; g=*; k=rsa; “
“p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Z4F”
“JEMHjJDuBmt25zvYFVejlARZGt1L8f0s1+rLxIPYkfCogQi+Y8”
“oLEg9vvEKnLx9aogZzuNt6j4Sty3LgXxaIwHnMqk0LldbA/mh3”
“wLZb16Wc6btXHON0o3uDipxqGK2iRLTvcgAnNDegseOS+i0aJE”
“nNSl663ywRBp/QKezhUC7cnbqR/H8dz8pEOjeawNN3nexdHGsk”
“+RaafYvCFvU+70CQORcsk+mxb74SwGT2CGHWxVywQA9yrV+sYk”
“JpxaufZLo6xp0Z7RZmbf1eGlCAdhkEy+KYQpQkw2Cdl7iKIK4+”
“17gr+XZOrfFLJ5IwpVK/a19m3BLxADf0Kh3oZwIDAQAB” )

ZZZzzzzz … I did say 😉