Re: Generic records and DKIM

On Wed, Mar 18, 2009 at 1:29 PM, Matthew Dempsky <[email protected]> wrote:
> The problem I was referring to isn't a tinydns limitation, it's a DNS
> limitation.  A TXT record's data is split into chunks at most 255
> bytes long.  A base64 encoded 1536 or 2048 bit key will be larger than
> 255 bytes, so it'll necessarily span multiple chunks.  If clients
> don't support concatenating chunks, then they can't support these
> larger keys.

I see this example in RFC 4871:

   brisbane IN  TXT  ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
                      "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
                      "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
                      "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
                      "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")

I'm not positive, but I understand this to be a TXT record split
across 5 chunks.  dig(1)'s output is consistent with this, but I don't
have a BIND server to test this against to confirm.

It seems like judging from that, there shouldn't be any problems with
tinydns-data splitting your TXT records into 127 byte chunks.  If it's
still not working with the s/127/255/ change, I suspect your problem
is somewhere else (e.g., publishing the wrong public key, formatting
the DKIM record wrong, etc.).