There is a fix possible here, but it requires either the creation of a
new RR or the repurposing of an existing RR.
Essentially the key to making wildcards work for prefixed records is to
create the ability to declare pointers for discovery of prefixed
records.
The main problem with DNS wildcards is that it is not possible to create
a mid-point wildcard:
_policy.*.example.com
The best solution to the problem is to introduce a policy pointer RR:
*.example.com PP _default.example.com
_policy._default.example.com TXT (Policy stuff here)
This allows policy wildcards and SRV to be supported without the need to
introduce new DNS RRs for each new protocol that is brought under the
scope of the policy control.
It also allows for much easier management in general. A large site would
be likely to group servers by function and apply distinct policies for
each server group. Each group policy would be maintained in a single
place and the machines assigned to that policy by adding the relevant
policy pointer.
The resulting mechanism allows the DNS to be extended on an ad-hoc basis
without the need for prior IANA RR assignment and without the problem of
competing policy records 'stomping' on each other.
I see absolutely no point in the current plan to transistion to an IANA
assingned RR. Nobody has the slightest intention of ever using the new
RR. It is only there because the DNSEXT group insists it be so. There is
never going to be an incentive to move from the TXT record to the
assinged RR. The TXT based record is always going to be more widely
supported, the code paths more thoroughly debugged.
The PP mechanism is interesting because it offers a concrete advantage
to upgrading your DNS server to support the new mechanism but DOES NOT
MAKE THIS A REQUIREMENT. The PP mechanism is largely compatible with the
DKIM deployed base:
* If you are a signer support for the PP record will simplify certain
management tasks but is not essential.
* If you are a verifier lack of support for the PP record will mean
that the verifier is unable to see wildcarded policies but the
signatures created under those policies will stil be verifiable.
This is a much better set of incentives than you get with an entirely
new RR that is intended to replace the prefixed TXT record. Here the
signer has to create dual TXT and DKIM records if they want them to be
visible. Publishing the same information through two channels is never a
good design practice. I suspect that few sysops will publish the DKIM
records until they are universally supported. I doubt that many
verifiers will check the less frequently used record first regardless of
the demands made in the specification.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Tony
Finch
Sent: Tuesday, August 02, 2005 6:48 PM
To: IETF MASS WG
Subject: wildcards, was Re: dkim technology?
On Thu, 14 Jul 2005, wayne wrote:
One example, is the language about the new DNS RR types
probably won't
be accepted by the folks on namedroppers, and I can give some
suggestions about what will be more likely to be accepted.
I suspect
that the tree-walking in the current draft will also be
very unpopular
with the DNS folks.
Where is the tree-walking stuff in DKIM? I can't find it in
the current draft.
(On an off-topic tangent, because this hasn't been made clear
in this thread so far, the specific problem with CSA and
wildcards is that SRV is, in general, incompatible with
wildcards: if you try to blanket a zone with wildcards in
order to ensure that all invalid EHLO names within the zone
have negative CSA SRV records, including those names that do
not otherwise appear in the DNS, then you'll also return
bogus SRV data for any SRV query on any name in your domain.
Wildcards are less problematic with other RR types.)
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT
FIRST. MODERATE OR GOOD.