ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM DNS record types

2005-11-15 14:49:04

On Nov 15, 2005, at 2:10 PM, wayne wrote:
I think that anything that looks or acts differently than the TXT
record is going to cause confusion.

If it looks like a TXT and quacks like a TXT, why not just use TXT?

If the output of a "host -t TXT snake._domainkey.yahoo.com" looks
different than "host -t DKK snake._domainkey.yahoo.com", you are going
to cause confusion.

And if the output of "host -t TXT snake._domainkey.yahoo.com" looks different than the output of "host -t TXT snake._domainkey.yahoo.com" because one is using BIND X and the other BIND Y, this will also cause confusion.

Oh, you missed the one big feature I can see with not using TXT:
Strict syntax checking can be done at the time the zone file is
loaded.

Covered in point #3.


On Nov 15, 2005, at 2:15 PM, Mark Delany wrote:
Right. If that is the path to take, let's make it similar to a TXT but
withut the problems. Say,

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+
       |         Length                |   value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+

A 16bit unsigned length followed by txt.

If you gonna just do a blob, what's wrong with just the RDATA length that is already there? Perhaps there is some DNS nuance I'm missing.

My initial thought on this was:

                            1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
       |  Tag    |Type |  Length       |   value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+

Or we could drop the type and make it implicit in the tag name.

It will be interesting to see that in practice given that most master
files I've seen are positional and DKIM has numerous optional
tags.

Good point.

Would it end up looking something like this?


    IN  DKIMSEL 1 rsa sha256 -  -  - 34E7BC... - "marketing"

I wonder if we could get away with:

  IN DK v=1; a=rsa-sha256; h=from:to:subject:date; b=dzdVy...

Note I'm not advocating a surrogate TXT at this time, just discussing
the options and implications.

Same here.

-andy

_______________________________________________
ietf-dkim mailing list
http://dkim.org