Use of New Mask Mechanism

The DNS Load Research thread is getting way to long with too many 
topics.  Let's start a new thread to work out the details of how the new 
mask mechanism should be used.  Radu has a good start with his procedural 
outline below.  I inserted one added condition, based on my current 
understanding of DNS, which may be flawed.
SPF users should be urged to keep their compiled records simple (list of 
IPs only) and shorter than 450 bytes.  Our Best Practices document, and 
some good examples of large domains like rr.com, should show that this is 
possible.  The advanced mechanisms should be documented in an appendix, to 
be used only for the rare cases where they are truly needed, like an "SPF 
Obfuscation Contest" :>)
We might want to consider a different syntax for the mask mechanism, 
considering how difficult it has been to explain, even to the experts on 
this list.  I suggest a simple "not" operator, which complements whatever 
follows.  -!ip4:65.122.44.0/24 means reject any IP *outside* of the given 
block.  This term would be evaluated in the normal sequence, like any 
other.  To be useful, the compiler would always place it at the beginning 
of the record.
At 12:15 AM 3/26/2005 -0500, Radu wrote:

> 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.
Masks should be added to a list of IPs, only if that list is already too 
long to fit in one 512-byte DNS response message.  In this case, a mask may 
allow the SPF check to return a FAIL without initiating a TCP connection to 
retrieve the full DNS message.
>    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.
-- Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *