Re: Re: DNS load research

Scott Kitterman wrote:
> > -----Original Message-----
> > From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
> > [mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Radu 
> > Hociung
> > Sent: Friday, March 25, 2005 3:58 PM
> > To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
> > Subject: Re: [spf-discuss] Re: DNS load research
> >
> >
> > Frank Ellermann wrote:
> >
> > > Radu Hociung wrote:
> > >
> > >
> > >
> > > > So why not use m=65.0.0.0/6 ?
> > >
> > > Tricky.  Old implementations ignore new modifiers.  And new
> > > implementations are free to ignore them.
> > I'm counting on this. :)
> >
> > I claim that while the new mask introduces DNS traffic savings, it does
> > not break existing implementations or published records in any way.
> >
> > Old implementations ignore it and don't save. If you believe in the old
> > saying "a penny saved is a penny earned", it means that old
> > implementations are missing out out opportunities to be more efficient,
> > and they will be obsoleted in time.
> >
> >
> > > You could very easily
> > > get it wrong, a sender policy resulting in FAIL with some new
> > > implementations, and other results with other implementations.
> > Maybe my description of this modifier was not clear enough.
> >
> > The -m=65.0.0.0/6 means:
> >
> > Nowhere in the following SPF records and their included or redirected
> > records exist any mechanisms that would match an address *outside* of
> > the 65.0.0.0/6 net.
> >
> > The mask does not contradict the rest of the record.
> >
> > At the same time, you MUST not assume it means "any sender with an
> > address in the 65.0.0.0/6 block is a permitted sender".
> >
> > Also, you have to look at *all masks* and only if none of them apply to
> > the IP in question, the processing should continue.
> >
> > In the case of a long-winded daisy chained record, the '-' also brings
> > the default mechanism (-all) from the very last record up to the
> > top record.
> >
> >
> > Due to the restrictions I outlined for when a mask must not be included,
> > think I coverted all cases that would cause unreliability.
> > If I missed something, please let me know.
> >
> >
> >
> >
> > > Not exactly user-friendly.  And looking at the exactly _zero_
> > > feedback I got for the updated "op=" draft I doubt that anybody
> > > is interested in new modifiers.  Especially no SPF implementor.
> > I wasn't interested in user-friendly, because the mask can only be added
> > reliably by a compiler (a machine). Because to get a good mask is
> > difficult, it is also error prone. I would not want hand-coded masks,
> > that's what will cause the unreliability you mentioned (mask and record
> > mismatch).
> >
> > The spfquery debug mode will check for these rules, and tell when a mask
> > doesn't match the record, or when it has the potential to be unreliable.
> >
> > So from this point of view, the more user-unfriendly it is, the better.
> > Users should *never* add masks to their records. If the compiler decides
> > it would be beneficial and safe to add one, in the context of the output
> > it is providing, it will add one.
> >
> >
> > > OTOH you're an implementor, you could guarantee that there's at
> > > least one implemetation for your mask-modififier.  If you need
> > > an XML template for an indepedent draft use my old "op=" draft,
> > > see draft-spf-6-3-options-04.xml and the corresponding txt in
> > > <http://purl.net/xyzzy/home/test/>
> >
> > Thanks, the day will come when your document may come handy.
> >
> > Radu.
> I've read through this a few times and it isn't clear to me how this is
> different than -ip4:.
>
> How would:
Let me quote the rules for creating masks first:

If no compiler
   1. there is no masking, or you'd have to insert it manually,
   which is inconvenient and error prone.

elseif compiler is used
   2. If compiled with cron, or once in a while, -flatten should
   not be used. There will be left-over mechanisms whose
   resulting IP address may change (administrative gap)
   Thus, masks MUST not be added, since while they work initially
   they would break the record when the ISP changes their
   infrastructure.
   3. If compiled with cron, and -flatten not used, but the record
   compiles into a list of IPs anyway (ie, you list no mechanisms
   that lie outside your adminstrative boundary), then it may
   include masks if useful.

   4. Masks can only be reliably inserted when your record is
   completely in your administrative control, as above, or if
   the compiler runs as part of the DNS server.
   5. In that case, the record can be safely flattened *only if*
   the TTLs of all mechanisms are respected,
   including those across the domain boundary. In that case, the
   record, and implicitly the mask get regenerated every time
   the IP list gets regenerated beause of expired TTLs. So,
   the mask always reflects the current record.

   Also, there's an additional condition on inserting masks.
   6. A mask may only be inserted if all mechanisms that cannot be
   compiled into an ip list (those that use the %{l} or %{i} macros)
   are brought up into the top TXT record.
   In other words, a mask may only be inserted if the remaining
   mechanisms in subsequent redirects/includes contain only
   IP lists.
end if.


I will need to sit down and comb through these more carefully for any 
corner cases, so don't take them as set in rock yet. I think the 
intention is clear though, and we'll work with the set of rules, keeping 
the intention in mind if ambiguities appear.
First and formost, the record with the -m mask is not legal unless it 
was created by a compiler. We really don't want people creating these. 
The compiler should not have left the A and MX records in, since they 
are at the same level of administration, so they would have been 
expanded into IP lists. Likewise for the include. If there were any 
references outside of control, the -m= would not have been added:
It looks like the include:example.net points to a different domain that 
is not under the same administration control of the SPF record. So, 
based on rule 4, this SPF record is not legal.
I think it should be specified that the checker should not attempt to 
verify if the masks are legal or not, but trust them implicitly. This is 
because in order to assert whether the mask is legal, it might have to 
expand one or more redirects to make sure they don't contain references 
to A, MX, include, etc. records that are outside administrative control. 
Likewise, to check whether a mask mismatches a perfectly within control 
record set, it would have to expand all includes and redirects. That is 
counter-productive.
The spfquery program can check the masks but only in debug mode, or some 
other -checkmasks mode. Using this, an implementation of SPF can check 
the mask output of another, and perhaps even give quality statistics on 
the masks it finds.

> > "v=spf1 ip4:65.0.0.02 -m=65.0.0.0/6 a mx include:example.net a bunch of
> > other stuff -all"
> >
> > be processed differently than:
> >
> > "v=spf1 ip4:65.0.0.02 -ip4:65.0.0.0/6 a mx include:example.net a bunch of
> > other stuff -all"

so I can't look further into your mask example because it violates 
several prime directives.
A more likely comparison would be this:

ex.net "v=spf1 ip4:65.0.0.2 include:_s2.ex.net -all -m=65.0.0.0/6"
_s2.ex.net "v=spf1 ip4:65.0.0.7 ip4:67.254.254.15 -all"


versus:

ex.net "v=spf1 ip4:65.0.0.2 include:_s2.ex.net -ip4:65.0.0.0/6 -all"
_s2.ex.net "v=spf1 ip4:65.0.0.7 ip4:67.254.254.15 -all"


If he IP address to check is say 65.1.1.1, then both ways yield the same 
"fail" result.
I think the problem is readily visible if you assume the address to 
check is 65.0.0.7.
In this case, evaluating the mask example, the -m modifier tells the 
checker to do more queries, because there are more addreses matching 
65.0.0.0/6 further in the record (such as 65.0.0.7, or others). When 
evaluating _s2, a positive match is found, and evaluation ends with "pass"
In the example without the mask, the -ip4:65.0.0.0/6 mechanism tells the 
checker exactly the opposite, that no addresses from that net are 
allowed to send, and the evaluation completes there with a "fail"

Radu.