On Mar 26, 2009, at 7:05 PM, Dave CROCKER wrote:
> well, now I'm completely confused. to my eyes, your example fits
> exactly what 'registered' and 'resolvable' mean, but I guess you
> have something else in mind.
>
hatstand.beartrap.blighty.com doesn't resolve. A query for it returns
NXDOMAIN, and it doesn't exist in DNS in any way:
steve$ dig hatstand.beartrap.blighty.com txt
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12223
Yet it's potentially a valid SDID, because
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com *does* return
a TXT record.
steve$ dig +short
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com txt
"I am a public key - no, really!"
Not only does hatstand.beartrap.blighty.com not resolve, it's not
registered anywhere. It exists solely as a substring of the string
that's actually queried -
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com
The only thing that can be said about the SDID in DNS terms is that
the signer of the mail has the ability to add TXT records in the
subtree rooted at that domain.
Given that, trying to make more specific statements about what the
SDID is than something vague like "a domain name" is likely to lead to
something that's misleading or plain wrong.
-1 on "registered" or "resolvable".
Cheers,
Steve
> RFC 1034 and RFC 1035 make many references to resolvers.
>
> d/
>
> Steve Atkins wrote:
>> On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote:
>>>
>>> Steve Atkins wrote:
>>>> On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote:
>>>>> We could say "DNS-resolvable".
>>>> We could, but it's not actually a requirement that the SDID
>>>> resolve in the DNS (and in many cases it won't).
>>>
>>> Really?
>>>
>>> Then how does the receiver obtain the public key for performing
>>> verification?
>>>
>>> key retrieval is defined as using d=.
>> If you receive an email with a selector of banjo.aardvark and an
>> SDID of hatstand.beartrap.blighty.com then you'll hopefully be
>> able to resolve
>> banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but
>> that's all you can say about ability to resolve any query in the
>> domain tree under the SDID, including the SDID itself.
>> At least, that's how I understand it.
>> Cheers,
>> Steve
>> _______________________________________________
>> NOTE WELL: This list operates according to
>> http://mipassoc.org/dkim/ietf-list-rules.html
>
> --
>
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
