I'll second that. Y! defers everybody, it's just a fact of life. But I send about 2 million emails a day to the big-5 and don't use DKIM. I hope we don't end up having to, b/c it sounds like a real PITA.

The abuse being....a lower cache hit rate on caching DNS servers? We're talking about Akamai here, not wildcarding. DNS service just isn't that expensive to provide, and when you consider that ISPs actively encourage Akamai to have caching servers inside the cages on their head ends, I think the "more DNS queries" vs "lower upstream bandwidth usage and better latency for our customers" doesn't seem like a tradeoff they're complaining about.

Title hardly makes for argument (note I wasn't the one throwing around the ad-homs here); I just wanted to point out that I was speaking from experience.

I don't understand how this is a problem with http...connecting tcp around the world takes an enormous amount of time compared to udp. That's just reality. Remember the issue here isn't what my servers can deliver, but rather latency, which is a function of the global network I don't control. Using Akamai for DNS allows me to use Akamai for midgress and mostly avoid this.

Sorry for the late response, but:

1. Anycast doesn't always work well for tcp.
2. Anycast means BGP, which means large blocks of IPs if you don't want to get filtered, which are hard to come by these days.
3. One major benefit of Akamai besides latency is decreased dependency on ISPs often flaky routing decisions; anycast would go the opposite way and increase this.

As the senior systems engineer for a website with points of sale all over the world but datacenters only in the U.S., and a heavy Akamai user, I can tell you that the amount of time for a 301 (requires tcp handshake and http headers) vs the time for DNS is nearly an order of magnitude, so it's a no-brainer to use DNS for this sort of thing.

I know others and I have been saying this up and downthread, but seriously check out configuration management tools like puppet.

(1) is always going to start in Linux with creating your own repo (you can keep it in sync with just rsync, and sync things from your test repo to your production one after they pass testing) and creating RPMs (or .debs, whatever) for any custom software you're using.

Once you've got that in place, you can do (2) and (3) with your configuration management system, which will download new policy when the system comes on-net and enforce it continually even when off-net, just like Group Policy. Because the configuration is all text, you can easily programmatically edit it, keep it in version control, back it up, etc, and configuration management systems are completely object oriented for easy inheritance.

Of course this probably won't stop the maliciously brilliant or totally idiotic, but I've yet to see Group Policy do that either.

I don't understand how this is any different than puppet (or bcfg2/cfengine): change the classes a system is in, and bam! everything changes.

Now obviously puppet is a textual rather than graphical config system, but as someone who has to admin both, I find that much more convenient (can edit with sed, store in svn, etc).

The beauty of Linux storing basically all config in text files, even for desktop environments, is that you don't need some special tool to manage X, you just create a template for the config file and define what set of machines that template should end up on.