In <2005714113127(_dot_)302394(_at_)bbprime> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
[...] I suspect
that the tree-walking in the current draft will also be very unpopular
with the DNS folks. SPF removed the zone-cut idea in part because of
this opposition, and the CSV's tree-walk wasn't any better accepted.
using zone-cut quite simply violates dns semantics. zones are an
administrative construct, not a name-space construct.
I disagree that the zone-cuts "violates DNS semantics". Zone cuts
are already exposed for "real" DNS wildcards, for DNS dynamic updates,
for DNSSEC, and maybe for a few other things.
While the mapping of "zone file administrator" to "appropriate
administrator of email sender policies" is not perfect, I think it is
*FAR* better than doing a tree-walk.
In particular, I suspect that the admin of, say, co.uk, will not
appreciate the idea of having to deal with DKIM lookups and at the
same time, the domain owners under co.uk will not appreciate the idea
of someone outside their administrative control being able to decide
email sender policies.
the tree-walk model is a very difficult compromise. for csv we explored
this issue at very great and very painful length. there is no question
that the result is ugly. the problem was that there seemed to be no other
way to deal with site-wide "policy" records.
I suspect that the DNS gurus will give us (people interested in DKIM)
the same response as they gave SPF folks: You can create a server
side macro processing that automatically adds the appropriate records
to the zone file before it is published. The secondary NS will then
be able to pick up these extra records when they do an AXFR.
In the longer run, I think quite a few people will start talking about
doing a better wildcarding mechanism. I dunno if that will go
anywhere. It needs people to actually do the work. I know that I,
for example, have failed to pick up the ball and run with it.
-wayne