Dns challenge signature is too long for dns TXT record about acme-spec HOT 6 CLOSED

ref: RFC 1035 Standard RRs

"character-string" is treated as binary information, and can be up to 256 characters in
length (including the length octet).

from acme-spec.

255 characters is the single string limit, a TXT (or SPF) record may exceed this limit by using multiple quoted strings in the record which the reading application must then concatenate, ISC Reference/RFC4408, i.e. TXT "..." "...". If we were to use multiple records we would require a way to make sure returned TXT strings were concatenated in the right order, and that no other TXT records are present that could foul up the JWS object.

from acme-spec.

Even with multiple TXT records, it requires that the dns server keeps the TXT records order, and from what I've seen during my tests, it's not always the case. Also it will most likely require to use tcp for dns queries (also not supported by all dns servers).
Using a hash of the signature offers the same level of trust, without those potential problems

from acme-spec.

This will be fixed if #223 is merged

from acme-spec.

There's a bit of misunderstanding here. TXT records may contain multiple character strings and each character string can be 0 to 255 bytes. The maximum number of character strings that can be contained within a single record is limited only by the resource record length field (RDLEN) which is 16-bits and by extension ultimately whatever else is within a given message. (Messages also have a 16-bit length limit and there's the 12-byte header, question and other RRSet fields to take into account.) The order of character strings within a given TXT record is always preserved.

from acme-spec.

Yes, you are right. I figured this out by reading the spec again.
I still consider short records should be preferred, for easier configuration and maximum compatibility.

from acme-spec.