Gary Levell writes:
Seth Goodman writes:
<snip>
For a few extra characters, no one would be confused.
Considering the recursion depth of DNS queries, the extra
characters are decimal dust in the total overhead picture.
I agree. I think Roger was worried that the UDP limit might be
reached if someone like AOL who uses predominantly ip4 mechanisms
wanted to have a policy for each scope (god forbid) and that
this might have an impact on that, so I stuck to the abbreviations.
I'm not wed to this idea.
I agree with this.
Current RFC proposal has nothing about maximum SPF record length.
I'm unaware if it 65000 (TXT DNS limit), 1400 or 512.
I would like writer clarify length for a records.
As well there is nothing about DNS string compression.
IMHO, I would like to be able to use numerous but short records.
Some kind of continuation ("cont:spf123") commands or new meaning to
"include" and "redirect" are a must.
"redirect" can not be used for long records continuation as it change
<current-domain>.
But "include" can work if we can create same sub-domain records - but this
will make include command long - at it will requere full name of
continuation record.
For example take a look on following user scenario:
Today is 2015. SPF widely used and your domain use aggressive "rule rule ...
rule -all" (it's pretty long - up to 14-20Kb) record to ingore all unknown
mail servers.
But due to server failure or network outage all your IP address changed and
you are unable to send emails from allowed servers.
Your DNS server refresh 8 hours, default TTL is 1 day and Expire is several
days (per RFC1537).
Results - your bussiness stopped as you are unable to update SPF records
fast.
How to prevent this while keep reasonable system perfomance ?
You need to create main SPF domain record with short (about 1 hour) TTL and
inside it point to big rule for your domain (with long TTL like 6 or 10 days
;o).
In case if you need to change your rules - you create new (DO NOT edit old
to prevent outdated cached values use) rule and change pointer in main SPF
record to new rules.
This way in case of unpredicable outgoing server changes you will be able to
change them fast - while keep network traffic low as servers will simply
query version number of your SPF rules. Update 99.9% will be a little big
easier.
BTW, It will be nice to have some kind of versioning for SPF records by
design.
Main SPF record will give simply a version and alternative location of
rules. Using this short version number you can query for complete rule list.
(Tradeoff - traffic vs. speed of updated. IMHO, no needs to change this - as
it's can be possible to implement using modified "inlcude"/"redirect")
As well I would like RFC writer describe common practice how to change SPF
records to not loose emails.
Complete rules for "Change domain record data game". Changing TTL in
advance, creating extented (both old and new locations) temporary rules,
waiting one more TTL, move servers, change rule to new servers and reverting
TTL to regular value.
Such a change process is not trivial and must be documented for admins. Or
some kind of programmable solution or best practice created.
Thanks in advance,
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua