[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

> Additional arguement Con is that a new RR type takes a LONG 
> time to deploy.  
> In 2 - 5 years when this new RR type is deployed, whatever 
> problem it was trying to solve will likely be solved some other way.

The idea here is to balance the political constraints as well as the technical. 

People seem to demand that we have a new RR. There are four choices:

1) Ignore them and plough on regardless (from a technical point of view PTR records would serve as well as XPTR)

2) Begin using TXT records but promise to transition to a new RR at some future date

3) Accept a new RR to support wildcard capability

4) Accept a new RR to publish all policies.


The astute will recognize that option 2 results in the same exact outcome as option 1. Once there is infrastructure deployed to support TXT nobody is ever going to transition away from it. Option 2 results in the absolute worst case outcome, we end up supporting two parallel infrastructures for publishing the same data.

Option 4 is the next worst option, measurement of the number of Windows DNS servers out there shows that the number is significant. While it is possible to cause the Windows DNS server to emit the bit sequences for new RRs the procedure required to do so cannot possibly be considered to be acceptable as an administration option. Windows is a GUI based O/S and there is no support in the GUI for new RR types. Nor is there support to save a zone file with new RR types.

So that leaves us with options 1 and 3.


XPTR could be realized using PTR records. This was my original proposal. It is a viable technical proposal but it does redefine the semantics of an existing record. This usage does not cause conflict with any sanctioned uses but it might well conflict with non sanctioned uses.

My concern here is to make DKIM work as well as possible with the DNS _as_it_is_today_. So the concerns raised in the DNSEXT group appear to me to be reasonable.


XPTR is more efficient than any of the tree walking schemes proposed. In normal use the search will terminate in one or two steps. The only case where three steps are required is if the attacker decides to attempt a particular attack that they do not currently have an incentive to attempt and is certain to fail. Ergo I do not accept Jim's claim that the possibility of a third lookup should be considered a performance hit against XPTR.

Nor do I see the logic in employing a heuristic tree walk rather than doing the job properly.


The DNSEXT group has every reason to accept the XPTR proposal when it receives the draft next week. It has been stated repeatedly that it is going to be easy to obtain new RRs. The XPTR feature will only be applicable to a prefix record if the prefix search strategy states that it is to be applicable. Moreover to reject XPTR would force me to employ PTR for the same purpose. 

More importantly XPTR provides a generic solution to the wider problem of heuristic hunt and peck discovery schemes that are causing real problems for core DNS. Half the DNS traffic is due to attacks. The other half is due to misconfigured servers. Legitimate use is essentially a rounding error.

Why should the DNSEXT working group be less willing to accept a solution that takes their architectural concerns seriously and attampts to deal with them in depth than one which represents yet another point solution?


We have to get along here with the rest of the IETF. That is the point of being in the IETF rather than OASIS. Getting along means taking real architectural principles and operational concerns seriously. It also means taking seriously the IETF wide concern that deployment of DNSSEC should be a priority. Getting along does not mean surrender or automatic compromise.