When a 2048 bit key is to be handled, with the 'g=' parameter
and a new hash callout, the space remaining is 93 bytes,
assuming a domain with 4 labels with a selector. From these
93 bytes, 5 labels, the local-part and hash function must be
defined where the average item size must be less than 14
bytes. When a binary DKIM Key RR is used, the remaining
available space is 192 bytes, which then allows an average
item size to be greater than 27 bytes. This provides twice
the available space, which is _not_ insignificant. The cases
where the DNS payload overflows would be much fewer.
Irrelevant, there is no space for a DNSSEC signature in either case,
unless DNSSEC itself supported either ECC or some form of signature
compression a la Schnorr.
There was not a suggestion to use a new binary record. The
proposal was to employ an existing record in a binary fashion.
It may exist on paper, it is not supported in the running code and
getting support is a long time off.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html