James Craig Burley wrote:
Do the local caches depend on locality of reference to achieve high hit rates?
If so, can you be *sure* that all SPF lookups for incoming emails will exhibit sufficient locality of reference to ensure those hit rates remain high?
You are looking at DNS from the "consumer" point of view rather than the "provider" point of view (which is where I am coming from). By setting a reasonable TTL on my DNS records, I am very confident that _my_ authoritative servers will not be hit by every yahoo with a resolver more than X percent of the time. The precise value of X depends on both how popular my domains are and how long a TTL I have assigned. I can ensure that _my_ e-mail won't be delayed due to timeouts for SPF records.
If not, can you be *sure* that latencies resulting from cache misses will not, due to overloaded upstream DNS servers, result in email deliveries being delayed or even failing due to persistent delays?
Any SPF query for a second level .COM domain should normally take 3 queries to different servers to resolve:
$ dnstracer -q txt -os . rowman.com Tracing to rowman.com via A.ROOT-SERVERS.NET, timeout 15 seconds A.ROOT-SERVERS.NET [.] (198.41.0.4) |\___ M.GTLD-SERVERS.NET [com] (192.55.83.30) | |\___ b.ns.rowman.com [rowman.com] (12.151.2.99) Got authoritative answer | \___ a.ns.rowman.com [rowman.com] (12.38.22.1) Got authoritative answer
(more queries would be involved only for subdomains, or for CC TLD's, which might have intervening servers). The root servers are pretty resiliant, and even the COM servers are heavily redundant, so that leaves only the last leaf node(s) as the source of any possible latency.
If not, what prevents spammers from targeting this weakness with an attack that culminates in a victim site disabling SPF, just as they've attacked system(s) offering C/R for popular mailhosting sites (like hotmail.com)?
I don't understand what weakness you see, so I cannot argue against it.
Nope. No need to do rDNS lookups to accept incoming emails. Since I turned that (and IDENT) off, incoming bounces of joe jobs from, e.g.,
Good for you. ;) You are missing my point in that I (and I'd guess the vast majority of the people on this list) am making multiple DNS queries for each inbound transaction, to no ill effect (most of the time). I am only interested in making sure that my outbound mail proceeds apace, which I can control by the appropriate use of _my_ SPF records. I could care less, in practice, if inbound mail takes 1 second, 10 seconds, or 10 minutes.
If I had a much higher level of inbound traffic, I could simply add MX servers until I reduced the load to acceptable levels of my own choosing. The MX servers aren't doing anything else, so I could care less if they are spending 90% of their time waiting for DNS queries to return, as long as they aren't saturated and dropping connections.
Yes, that's true. So, assuming someone trusts every connection between Root and your particular place in the heirarchy, they can trust you and your SPF records.
The only "trust" involved is the same as every other DNS transaction: follow the chain of delegations down from the root. The only server which is authoritative for *my* SPF records is *my* server. If a user trusts their resolving cache, the cache will follow the chain and get the appropriate answer, just as if they looked up the MX record.
If they are running one of the BIND versions (or M$loth's NT4 resolver) which was susceptable to a poison cache exploit, they are screwed in any case. The SPF is the least of their worries.
But if they don't trust *any* connection in that chain, they must *not* trust you or your SPF records.
This isn't like a chain of authority in trusted certificates, where one untrusted link makes the chain untrustworthy. In DNS, _every_ query starts at the root servers and works down; there is always a clear chain of delegations, and as long as everything is configured properly, the query will be answered only by the server which is authoritative for that portion of the address space. If everything is not configured correctly, you won't get any answer (lame server). NOTE: here I am talking about your caching resolver (which will walk the chain IFF it doesn't already have an answer in its cache).
(That is, one cannot trust the SPF records for a.b.c.d.e if one cannot trust c.d.e to publish proper and trustworthy DNS info for itself.)
Again, you are missing the important feature of DNS that c.d.e must proactively delegate subdomains for them to be valid. No matter what a.b.c.d.e might want to publish, no one is going to get there to find out what that record contains if c.d.e doesn't delegate that range to another server.
For giggles sake, try these two queries:
dig login.oscar.aol.com
dig @12.38.22.1 login.oscar.aol.comThe first query will ask your default resolver to walk the chain from the root and will yield the 5 IP addresses for AOL Instant Messenger Login services. The second will bypass the normal delegation rules and ask my server for the answer. I'm quite the BOFH and I don't like AIM, so anyone in my network gets 127.0.0.1 if they try to resolve that host, and oddly enough AIM doesn't work here. :0
I can only do that because I control this resolver. I cannot control your resolver, so you get the correct addresses as published by the AOL servers.
Put another way: are you sure you will be able to trust *all* SPF records published in the .cn domain? The .ru domain? The .biz domain?
No, but I can make sure that someone claiming to be sending from jcb-sc.com is employing a server that the administrator of that domain has authorized to send from. SPF is not intended to prevent spam; it is intended to prevent forgery. It is just one more tool in the arsenel. I could very well only trust SPF for 2nd level domains only (third level for CCTLD's).
John
