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.
Tom, thoughts?
-Phil
