[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott
Kitterman
I think the burden here is to prove that a new RR Type is
both needed and deployable, not desirable and will get out
there someday.
I think it is an entirely rational concern. XPTR creates a two level system:
1) ANYONE can publish a DKIM policy without upgrading their DNS server
To publish policy for example.com you publish
_dkim.example.com TXT "DKIM"
2) Wildcard policy publication requires a server upgrade
To publish policy for *.example.com you publish
_dkim.example.com TXT "DKIM"
*.example.com XPTR _default.example.com
_dkim._default.example.com TXT "DKIM NOMAIL"
OK so why did I decide to cave to the demands of the DNSEXT working group, not
just to get along.
The problem here is that REGARDLESS of whose scheme you use you are going to
need to deal with the problem that DNS wildcards do not have the semantics that
you would want as an administrator. As we have discussed ad-nauseam, a DNS
wildcard only applies to nodes in the zone which do not exist.
So to make any of these schemes work we need a DNS server with the ability to
manage macro-wildcards. This applies to Jim's schemes and to my schemes and to
anyone else's schemes.
If we have to add this capability to the DNS server there is not a significant
cost to an XPTR record.
But the key advantge here is that anyone can start DKIM signing and publishing
SSP records today. That is not the case for a new RR.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html