Re: Re: DNS load research

David MacQuigg wrote:
> At 08:51 PM 3/23/2005 -0500, Radu wrote:
>
> > It has been mentioned that the %{i} macro could be included in the 
> > query, and then the server could reply with PASS/FAIL. I think this is 
> > a bad idea, because all those queries are uncacheable, so this truly 
> > circumvents the benefits that were designed into DNS. When the DDOS 
> > attempt does happen, caching can really help lower the impact. It may 
> > be that I didn't understand the proposal well enough.
>
> Good point.  I hadn't thought of that.  Also, since the PASS/FAIL 
> response takes the same single IP datagram as a list of IPs, there is 
> not much to be gained.
Still, it would be extremely useful for the DNS server to help the 
client minimize traffic as much as posible in some way.
I would like to propose we add a new modifier that lists the general 
area of coverage of the SPF record.
For instance, ebay's record is 12 records, but can be compiled (by the 
DNS server, perhaps) to:
[root(_at_)sun src]# spfcompile/spfcompile_static -sender ebay.com -len 120
ebay.com             TXT "v=spf1 ip4:66.135.195.180 ip4:66.135.195.181 
ip4:66.135.209.192/27 ip4:66.135.197.0/27 redirect=_s0.%{o}"
_s0.ebay.com         TXT "v=spf1 ip4:64.4.240.64/27 ip4:64.4.244.64/27 
ip4:66.135.215.224/27 ip4:216.33.244.96/27 redirect=_s1.%{o}"
_s1.ebay.com         TXT "v=spf1 ip4:216.33.244.84 ip4:67.72.99.26 
ip4:206.165.246.83 ip4:206.165.246.84 ip4:206.165.246.85 redirect=_s2.%{o}"
_s2.ebay.com         TXT "v=spf1 ip4:206.165.246.86 ip4:64.127.115.252 
ip4:194.64.234.129/27 ip4:65.110.161.77 ip4:12.155.144.75 redirect=_s3.%{o}"
_s3.ebay.com         TXT "v=spf1 ip4:62.22.61.131 ip4:63.104.149.126 
ip4:64.68.79.253 ip4:64.94.204.222 ip4:66.135.215.134 redirect=_s4.%{o}"
_s4.ebay.com         TXT "v=spf1 ip4:67.72.12.29 ip4:80.93.9.10 
ip4:195.234.136.12 ip4:203.49.69.114 ip4:209.63.28.11 redirect=_s5.%{o}"
_s5.ebay.com         TXT "v=spf1 ip4:210.80.80.136 ip4:212.110.10.2 
ip4:212.147.136.123 ip4:213.219.8.227 ip4:216.113.168.128 redirect=_s6.%{o}"
_s6.ebay.com         TXT "v=spf1 ip4:216.113.175.128 ip4:216.177.178.3 
ip4:217.149.33.234 ip4:220.248.6.124 ip4:67.72.12.30 redirect=_s7.%{o}"
_s7.ebay.com         TXT "v=spf1 ip4:216.113.188.112 ip4:80.66.137.58 
ip4:212.208.64.34 ip4:216.113.188.96 ~all"
And it could use as many extensions (redirects) as the spec allows.

Without looking into too much detail, I notice that they use the 
following class A networks for their outgoing mail:
64, 65, 66, 67, 80, 194, 203, 206, 209, 210, 212, 216, 220.

If the first TXT record would BRIEFLY summarize this information, then a 
client would be able to stop processing if the IP being checked is not 
on that list.
I propose that we add a mask modifier that looks like this:

-m=64/6 m=80.66/16 m=192/3

This would cost 26 bytes that would save the client from doing the next 
7 queries to expand the redirects in the ebay.com TXT records. Perhaps 
it's not the most concise and restrictive mask possible, but I'm doing 
it manually, and it is tedious. It serves the purpose of the example 
just as well.
This would be the mask modifier.

It would be very tedious and error-prone to manually put this modifier 
in the record, but it would be no problem for a compiler, to even find 
the set of mask hints that provide the biggest bang for the buck 
(queries avoided/byte of extra information added).
The mask should be checked after the current record is evaluated, before 
doing a redirect or include. Ie, it does not cover IP's listed in the 
current TXT, but only IP's that are not visible until another query is 
done. Also, the modifier only covers IP addresses beyond a redirect or 
include, not EXISTS, MX, PTR or A mechanisms. In fact, if there are such 
mechanisms beyond the include, the mask must not be added to the first 
record, as it would cause the evaluator to "jump to conclusions" that 
may not be true if the A/MX/etc lookups are done. In  that case, it may 
be added on the second/third include/redirect if further evaluation 
would only reveal IP mechanisms.
Note that the first mask modifier includes a prefix. That is the default 
action given by the "all" mech of the record, and it could be ?, ~ - or 
+. It needs be given only once. If missing, the previously seen mask 
prefix will be used. If it is given multiple times with different 
prefixes, a PermError should occur.
After the first TXT record, if the IP being checked does not match any 
mechanisms and no mask modifiers, evaluation can be terminated and the 
mask prefix be given as the result.
Note that without the mask, the client would have to fetch all the 
records, up to the query limit, in order to find out what the default 
action is (fail/softfail/pass/neutral). This would happen for all 
forgeries. With the mask, most forgeries will not require more than 1 
DNS query to get the top record. Some forgers will slip through, and 
will require some additional queries to be made. The compiler can help 
with this too, by listing the reordering the IP mechanisms such that 
disparate IP addresses are in the top record, and using the remaining 
records for 'blocky' lists of IPs. Chances are high that when an ISP 
uses IP's that are close together, that he owns the whole block, so 
there would be no forgeries coming from within that block. Thus the 
accuracy of the prediction made by the mask would be very high.
The mask offers nothing more than an educated guess, and it is clear to 
show that even a mask like 128.0.0.0/1 will serve to avoid 7 queries 
half the time. At least it says if the connect is coming from the "left 
side" of the internet, don't bother with any queries, because we have no 
servers on that side of the internet. Of course, a decent compiler would 
do a much better job, and create a much more narrow mask.
There would be no limit to how many masks are provided. The compiler 
should optimize for the most benefit when it creates them. Ultimately 
the limit is 512 bytes * {lookup limit}. No other limit needs to be 
specified. This creates the opportunity for rogue NS servers. But since 
they will be supporting the costs (ie, the traffic generated as a result 
of providing inefficient masks will be the responsibility of the rogue 
server. I think this creates a very limited chance for abuse. Especially 
since query packets are small, but response packets would be big in this 
case. So the rogue server may saturate its own bandwith first.
The mask keyword is a short word, because there may be many, masks and 
we need to save as much space as possible. Since humans will never write 
masks, they don't need to remember what "m" is.
The m modifier is neither required to be included, nor required to be 
checked/used. This makes it backwards compatible with current records 
and SPF software.
It is not necessary to specify whether an IPv4 or IPv6 address follows. 
the parser can tell those apart very easily. If it has colons, it's 
IPv6. If it has dots or no punctuation, it is an (abbreviated) IPv4 address.
I wasn't here when the IP4 and IP6 names were chosen, or I would have 
made the same point there. The digit is useless. when you send through 
50 servers, that's 50 bytes more than are actually necessary to convey 
the information. But we should keep it as is now.
Comments ?

Thanks,
Radu.