SM wrote:
>> You can tell me if I am wrong here cause I am trying to make sure I
>
> It is not up to me to determine whether you are wrong. :-)
From an IETF procedural angle. :)
>> 1) Verifier TXT record parsing
>>
>> I checked for this, but did not find it, but was a quick scan.
>>
>> If the DKIM specs says that verifiers MUST be ready for different TXT
>> records merged in the DNS Query response, it MUST parse for the string
>>
>> v=DKIM1
>>
>> If this is the case, then I don't think we need to add anything. Its
>> all good.
>
> That tag isn't always included in the DNS record for backward
> compatibility with DomainKeys. And it is optional. As you are doing a
> query for a TXT RR, expect garbage.
>
>> However, in my personal engineering opinion, it probably should add a
>> note for verifiers to be ready for multiple string responses.
>
> From RFC 3833:
>
> Much discussion has taken place over whether and how to provide data
> integrity and data origin authentication for "wildcard" DNS names.
> Conceptually, RRs with wildcard names are patterns for synthesizing
> RRs on the fly according to the matching rules described in section
> 4.3.2 of RFC 1034. While the rules that control the behavior of
> wildcard names have a few quirks that can make them a trap for the
> unwary zone administrator, it's clear that a number of sites make
> heavy use of wildcard RRs, particularly wildcard MX RRs.
>
> Regards,
> -sm
The difference is that MX records are well structured fixed RR
records, where merged TXT records have a multi-technology mix with
multiple non-fixed structured definitions. So the client has to be
aware of all of them or be savy enough to look for what for what it wants.
But my question was:
If 4871 does not speak of requiring the DKIM client of parsing merged
TXT records to look for its specific inputs, then section 3.6.2.1
needs to make up for this dearth of verifier design information.
I ask because in Murray's suggested text:
"The use of wildcard TXT records in the DNS often result in
something coming back from a query that isn't a valid DKIM key
record
(and ADSP will encounter the same thing). Verifiers should expect
this to occur and plan accordingly."
I like it, but from an IETF standpoint, doesn't the last sentence
imply a 'change of code' thing that we try to avoid here?
I think the way it is stated was design to avoid this. Right?
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
