In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0507212101530(_dot_)12143-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
How many CNAMEs should an SPF implementation follow before returning
PermErr? SHould each CNAME link count as a DNS lookup for the overall
lookup limit? A quick example to make sure we're on the same page:
loop.example.com IN CNAME loop.example.com.
For what it is worth, I have set up the following for testing
purposes:
cnameloop.midwestcs.com. CNAME cnameloop.midwestcs.com.
Now, we *could* keep a stack and follow chains of arbitrary depth
while detecting infinite loops. However, that still makes a CNAME
DOS attack trivial:
evil0.example.com IN CNAME evil1.example.com.
evil1.example.com IN CNAME evil2.example.com.
Likewise, I have set up the following chain:
cname00 CNAME cname01
cname01 CNAME cname02
cname02 CNAME cname03
cname03 CNAME cname04
cname04 CNAME cname05
cname05 CNAME cname06
cname06 CNAME cname07
cname07 CNAME cname08
cname08 CNAME cname09
cname09 CNAME cname10
cname10 A 127.1.2.3
spfcname TXT "v=spf1 exists:cname00.midwestcs.com -all"
So, do an SPF query on foo(_at_)spfcname(_dot_)midwestcs(_dot_)com with any IP
address. You should get back a Pass.
These chains actually aren't that bad because the authoratative name
server sends out all appropriate CNAMEs in one packet, so this is only
a little more CPU intensive than just having a single A record. Ok,
the single UDP DNS packet is also a little larger.
These types of things don't have any real DOS amplification factor.
It could, if the chaining of CNAMES were done between different name
servers, cause some extra traffic, but that same traffic could be
generated just as easily other ways.
-wayne