[ietf-dkim] SSP issues

[Steve Atkins]

On Jun 2, 2007, at 2:37 PM, John Levine wrote:

>> As an aside, I don't believe there's anything that prevents use
>> of TXT records, as currently specced, with wildcards, other than
>> lack of support in the more widely used nameservers.
>
> It depends on what your plan for using TXT records is.  If you're
> planning to use a prefix like _ssp.example.com, internal wild cards
> like _ssp.*.example.com aren't ever likely to work because it would be
> a compatibility issue.  (Think of the fun when a secondary that
> doesn't handle them AXFRs a zone.)

That's exactly what I meant. You'd need to update your authoritative
nameservers to handle internal wildcards, if you were a sender who both
wanted to use SSP and had a vast number of potential sender
subdomains.

> There's been some suggestions for
> internal wild cards marked by ** but I gather that has unpleasant
> interactions with DNSSEC.
>
> The alternative is to do what SPF did, put the TXT record directly at
> the name and use version strings at the beginning of each record to
> tell them apart.  Beyond the gross ugliness, there's concerns about
> how likely client code is to reliably ignore the records it doesn't
> understand, and there may also be some issues where the names you want
> to wildcard for SSP overlap with the ones for SPF.
>
> We've gone around this enough times that I think that if there were a
> reasonable way to do wildcards with TXT records, we'd have stumbled
> across it by now.

If you exclude "fix the authoritative server" as an option, then
there isn't a reasonable way to do so. That's a reasonable
exclusion in general.

But... if the only problem is wildcard records, and only a small
number of senders are going to want to use wildcards with
SSP then the obvious engineering solution is to have those
small numbers of senders upgrade their DNS infrastructure,
rather than wait for the far larger number of potential recipients
to upgrade their infrastructure.

And, from what I'm hearing, those who are motivated to use
SSP at all are mostly senders. Having those with the motivation
be the ones who need to do the infrastructure upgrades
would likely speed deployment. (But so would having a
shiny new RR that's well designed and has desirable uses
outside the grubby little niche that is SSP.)

Cheers,
   Steve