On 27.02.2010 00:52, Phil Pennock wrote:
> On 2010-02-26 at 20:10 +0100, Sven Hartge wrote:
>> The lookup from the command line returns three results which in 4.69 were
>> concatenated with \n.
>>
>> oweh@skuld:~$ host -t txt 189.14.63.186.asn.fh-giessen.de
>> 189.14.63.186.asn.fh-giessen.de descriptive text "22927" "186.60.0.0" "14"
>>
>> I suspect the merge of the DKIM code in
>> f62bfb6fe50ab4abd1bba9eff5c458316d5322e5 to have created the problem, but
>> I am not fluent enough in C and the exim codebase to be able to debug or
>> fix it myself.
>
> I think you're right as to the cause.
>
> There's a bit of a problem here, in that the semantics demanded by DKIM
> differ from what Exim did before.
>
> RFC 4871:
> ----------------------------8< cut here >8------------------------------
> 3.6.2.2. Resource Record Types for Key Storage
> [...]
> Strings in a TXT RR MUST be concatenated together before use with no
> intervening whitespace. TXT RRs MUST be unique for a particular
> selector name; that is, if there are multiple records in an RRset,
> the results are undefined.
> ----------------------------8< cut here >8------------------------------
>
> However, if memory serves there is no DNS-level mandate that all TXT
> strings always be interpreted this way. Some DNS client specifications,
> such as SPF and DKIM, mandate this behaviour but it's in no way inherent
> to DNS TXT records themselves. Tony Finch might correct me if I'm wrong
> here.
>
> So the new behaviour is correct for DKIM and sometimes correct for other
> other protocols, but not correct for the general case and as such is a
> regression.
>
> Perhaps the best solution is to add a new pseudo search type for dnsdb,
> just as there's "csa", "mxh" and "zns". Call the new one "txtconcat".
> Revert to the previous behaviour for "txt", have dnsdb use txtconcat.
^^^^^ DKIM?
Or maybe introduce an option which allows the admin to set the seperator
himself, just like ">" works with multiple A,CNAME or PTR records.
This way one could get a string like "22927:186.60.0.0:14" and process
this further. The default should be \n for backwards compatibility.
Grüße,
Sven.
