Re: Re: DNS load research
2005-03-26 07:33:02
Frank Ellermann wrote:
Radu Hociung wrote:
In the example without the mask, the -ip4:65.0.0.0/6
mechanism tells the checker exactly the opposite
Yes, and now I see why -m is unnecessary: There are already
at least _two_ solutions for this case working today.
-1- Exclude all CIDRs not covered by 65.0.0.0/6
-ip4:0.0.0.0/2 -ip4:128.0.0.0/1 -ip4:96.0.0.0/3
-ip4:80.0.0.0/4 -ip4:72.0.0.0/5 -ip4:68.0.0.0/6
-2- "antimatch" 65.0.0.0/6
me.example IN SPF "v=spf1 -include:not.me.example ..."
not.me.example IN SPF "v=spf1 -ip4:65.0.0.0/6 +all"
Same effect as -m=65.0.0.0/6 and working everywhere. Bye
functionally, they would be equivalent, of course.
While the first one does not require queries, it is very space
inefficient. As you've shown, the tighter the mask (ie, the higher the
CIDR), the more space - in bytes - it requires.
The second one requires at least one query. It may be an acceptable
solution until checkers with mask capability are widely deployed. But:
1. It still requires the deployment of compilers. I'd rather put out the
best compiler I can.
2. It is half as good as the mask modifier. It gets most of the way
there functionally (ie, in the ebay case it would save 8 of the 9
redirects, but cost one). So the minimum number of queries to identify a
forgery in the ebay case is 2, compared to 1. Not to mention that for a
record that already uses up all the queries required by the
standard-specified lookup limit, it would not be usable, because it
would increase the overall query count.
3. Since the method would be much better than no masking, then the
incentive to adopt the mask modifer would be lowered.
It is a good idea though, I thought about it before also, and it may be
a good tradeoff for a compiler that supports masks to provide a setting
that can be enabled to turn on generation of -include based masks. That
way, DNS admins can realize a lot of savings immediately, and still be
able to switch to the more efficient m= masks later when adoption is
higher, in order to cut their SPF-related DNS bandwidth in half (from 2
queries to 1).
It is a little more effort to figure out when it's worth inserting and
when not. For instance, for a record that spans 2 TXTs with 1 redirect,
it's not worth it. For a records that spans 3 TXTs with 2 redirects, it
may or may not be worth it. For records that span more TXTs it may
become unquestionably worth it. I'll have to do more numbers.
Thanks,
Radu.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Re: DNS load research, (continued)
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Andy Bakun
- Re: Re: DNS load research, Andy Bakun
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research, Radu Hociung
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research, Radu Hociung
- RE: Re: DNS load research, Scott Kitterman
- Re: Re: DNS load research, Radu Hociung
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research,
Radu Hociung <=
- Re: DNS load research, Frank Ellermann
- Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
|
|
|