On Monday, August 26, 2013 16:28:03 Douglas Otis wrote: > On Aug 26, 2013, at 3:48 PM, Scott Kitterman <scott@xxxxxxxxxxxxx> wrote: > > On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: > >> Please also note that the PTR RR is not constrained in the current > >> specification and can create erratic results. It would be far safer to > >> Perm error when overflowing on the number of PTR records. There is no > >> upper limit as some represent web farms hosting thousands of domains. > > > > This exact issue was the subject of working group discussion. Since the > > number of PTR records is an attribute of the connect IP, it is under the > > control of the sending party, not the domain owner. A cap that resulted > > in an error would, as a result, enable the sender to arbitrarily get an > > SPF permerror in place of a fail if desired. The WG considered that not > > a good idea. > > Dear Scott, > > It is within the control of the Domain owner about whether to make use of > the ptr mechanism in their SPF TXT. Random ordering or responses is also > controlled by the IP address owner and not the Domain owner. The ptr > mechanism may offer intermittent results that will be difficult to > troubleshoot. By offering a Perm error on a ptr overflow, the domain owner > is quickly notified this mechanism should not be used and are not fooled by > it working some of the time. The greater concern is in regard to the over > all response sizes when DNSSEC is used. In that case, response sizes can > grow significantly. Allowing large responses to occur without producing an > error seems like a risky strategy from the DDoS perspective. That is also > another reason for worrying about the use of TXT RRs. How many large > wildcard TXT RR exist, and if they do, who would be at fault when this > becomes a problem for SPF? Your conclusion is different than the one the working group reached. Scott K