Re: [dnsext] Advice sought on DNS file format for new RRs

[Michael Graff <[e-mail]>]

On 11/19/10 5:56 PM, Phillip Hallam-Baker wrote:
> The constraint here is that if I have a complex binary format, then DNS
> servers are going to have to be able to parse a correspondingly complex
> syntax to encode the data. That may not be desirable.

I really hate to suggest this, but could you go back to basics?  What is
the data item you are attempting to transmit?  I admit I stepped into
this conversation in the middle, so if there are references I should be
reading kindly point me at TFM.

If a single block of data is the goal -- that is, the concept of "a key"
or "a certificate" or something, where you really don't want to split
the individual components of those items up, why split them at all?

With a custom type, you have to choose two things:  textual
representation and wire format. I would take the idea of using a TXT
encoding right off the table from the start so you are free to choose
more efficient wire format than a TXT-like encoder would typically use.

> That is not the case in DKIM.
> 
> In DKIM the key blobs are encoded in base64 and that is how the data is
> stored in the DNS TXT record.

If they had used a custom type, that would not have happened.

TXT is the record they chose, and of course it's a literal translation
from what is in the zone file to what is on the wire.

> The TXT approach appears to work in DKIM because the records in question
> do not affect the operation of DNS itself. 

It appears to work, but each user who overloads TXT has to deal with all
the other crap that may be there, now or in the future.

--Michael