[ietf-dkim] New Issue: Use of XPTR records in SSP

[Hallam-Baker, Phillip]

> [mailto:ietf-dkim-bounces at mipassoc.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.