Re: Re: DNS load research

Andy Bakun wrote:
> On Wed, 2005-03-23 at 17:57 -0500, Radu Hociung wrote:
>
>
> > > That is not what Radu said!  He made no claim that the virus would stop,
> > > just the DDOS attack.  In fact, he did not say the DDOS would stop, just
> > > that the internet would be back on its feet.  Maybe not running, but
> > > standing anyway.
> > Thank you Guy, that is exactly what I meant. In fact, removing the TXT 
> > records would only take the amplification factors away. At that point 
> > this virus would become as tame as any other.
>
> Okay, I see what you're saying.  Agreed. 
Cool :)

I was thinking some more about the scenario, and I think that the 
following conclusion did not came across very well:
The severity of the DDOS is a quadratic function of the query limit 
implemented by the spf checkers.
Each of the two multiplication factors are linear functions of the query 
limit. Since they get multiplied, the overal result is proportional to 
the square of the query limit.
Indeed, if the query limit that ohmi.org would do were 10 queries, the 
numbers would become (L=limit):
Traffic magnification: (2 * L * 100) / 60 = 33.33
Time magnification: (200ms * L) / 50ms = 40
Total amplification: 33.33 * 40 = 1,333
Aggregate DNS traffic: 1,333*1Mbit/s = 1.33Gbps

Here's a quick table I put together that shows the growth, for the 
assumed network conditions I specified (60-byte attack packet, 100-byte 
query packets, 50ms connection time, 200ms DNS query round trip):
Limit   Traffic amplif. Time Amplif Total Amplif:
1            3.33            4          13.33
2            6.67            8          53.33
3            10.00           12         120.00
4            13.33           16         213.33
5            16.67           20         333.33
6            20.00           24         480.00
7            23.33           28         653.33
8            26.67           32         853.33
9            30.00           36         1080.00
10           33.33           40         1333.33
11           36.67           44         1613.33
12           40.00           48         1920.00
13           43.33           52         2253.33
14           46.67           56         2613.33
15           50.00           60         3000.00
16           53.33           64         3413.33
17           56.67           68         3853.33
18           60.00           72         4320.00
19           63.33           76         4813.33
20           66.67           80         5333.33

The existing records that max out due to loops which are not easily 
detectable, combined with the existing checkers based on the current 
version of the draft (111 query limit) make a dangerous combination, in 
my view. Fortunately they are relatively few.
I think that in selecting a limit for the SPF draft we need to keep in 
mind how a potential DDOS would scale.
If DNS servers would include a record compilation function, then it 
would be no problem to have a very low limit for SPF records that are 
given by authoritative server to queries, and an arbitrary, much higher 
limit for the records that the compiler uses as input.
In that case, the spec might say something like "receivers must check up 
to X queries; if a record is hosted on a compiling server, it must 
compile to an equivalent record of X or fewer queries; otherwise, it 
must contain no more than X queries". Note that when a record gets 
compiled, it is the number of resulting bytes that matter ultimately. If 
you list a single A mechanism that has 1000 IP addresses, then that 
would require more than X linked records after compilation. On the other 
hand, if you have a very convenient record that contains lots of 
redundancies, it may reduce to a very small record.
I'm beginning to think that mechanisms with {ip_addr} and 
{sender_username} macros should be limited to 1 per domain, because 
they're not cacheable. {d} and {o} macros can be allowed anywhere, as 
they have no consequence on caching, but this may need more careful 
consideration.
Thus, the record configured by the zone admin and the record served by 
the server software would be completely different, but equivalent. The 
former would be heavy with convenient A, MX, INCLUDE mechanisms, while 
the later would be a list of IPs ending in a redirect.
I think the compiling-DNS server idea is brilliant, and it is just the 
solution to the DDOS problem described, but only if it is coupled with a 
low limit on the checker processing. Otherwise, it's marginally useful.
The version of libspf2 that I am working on will include compile 
functionality, and I will also demonstrate a patch to MyDNS that 
implements a built-in compiler. I suspect it will be a very simple patch 
as the compile function is in the library. Then perhaps others can 
follow the example and create patches for other name servers.
If standardization of SPF is some time away (1 year or more), there will 
be plenty of transition time for NS servers to be updated. Note that not 
all domains will need to update their server, they can simply use 
spfcompile and $INCLUDE its output, or just publish records that comply 
with the draft. Public NS services that allow users to publish arbitrary 
TXT records will likely want to consider updating, in order to offer 
maximum convenience to their customers.
This way, the DNS servers are not _required_ to be upgraded. If not 
upgraded, the records published through them will have to be cheap. If 
updated, the records published through them will be convenient. I think 
this will be a good incentive for those who want to publish convenient 
records to upgrade, without forcing anyone else to upgrade.
Some discussion happened before on how the record is compiled, and the 
TTLs. This will be very important to get right. For instance, the 
compiled TTL record should have a TTL of the shortest TTL among the 
expanded mechanisms. (if you list a 3-hour A record, the compiled TXT 
will have a 3H TTL; but if all your listed mechanisms have a TTL of 
2-days, the compiled record will also have a TTL of 2 days). Thus, the 
compiled record will be TTL-equivalent to the input SPF record. Also, 
the SPF record doesn't need to be compiled more often than its resulting 
TTL. Also it will be compiled once when the zone is reloaded or the 
server started, and the compiled version will never be stored and 
reloaded into an active server (ie, it will be a dynamic compiled 
record, not a static compiled record).
The libspf2 library I am working on is doing all these things that I 
describe.
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.
Regards,
Radu.