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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html