I figured. And also considered the sub-delegation. Only one problem. More often than not the website "www.domain.com" also wants "domain.com" pointing to their service. If you point it all at the 3DNS, that kind of blows the sub-delegation theory.

Yep. That hoses it.

AND, if you sub-delegate the "www.domain.com" and put an entry in the domain.com zone record on your regular DNS server - it can be managed OK for a few domains, but what about when you have a very large server farm... [eyes rolling] gads!

Presumably this is for large server farms that server large numbers of domains. I would guess this is why Akamai is selling their services for DNS as well as content now.

We should all hammer on Vixie or ISC to get this in BIND anyways. Wouldn't that be sweet and save us all $30-40k per device....

This would solve only half the problem -- one of the main advantages of the 3DNS product (and DDirector, probably) is its integration with its local load balancing brother. There's a fair amount of logic you've got to have the node local to the servers -- at the simplest level, returning a metric based on RTT to the querying nameserver. However, the 3DNS software on a BIG-IP is also figures in the current # of connections based on capacity, etc. The tiers of features would be 1) round-robin with node failure indication 2) metric based on RTT and 3) F5 supposedly is going to put its iQuery protocol on the RFC track, however I hope it will have a new name by that time to alleviate confusion with the DNS opcode and to not match /^i[A-Z]/. For ISC to go to the trouble, there would need to be more support than just F5, but there's the chicken-and-egg problem of Cisco not wanting to give up their DDirector sales by allowing the LDirector to seamlessly integrate with F5's product. Given that they're picking up $30-40k per box to do this, having it commoditized (either by an ISC implementation of their own protocol, or supporting a 3rd party protocol) wouldn't seem like a business wise decision. Perhaps some of the end-user ISPs could shed some light -- how topologically close are your forwarding nameservers to the end user? ... All of this still doesn't answer the underlying problem that any solution to this problem is going to suck, its just a question of how bad. Given the opinions on BGP for this application so far, DNS seems the only feasible place to implement this with the current infrastructure. If a forwarding dns server were to include the host on whose behalf it was asking (...hoping of course that in NAT'ed situation, the name server would be outside of the NAT) then some _very_ nice things could be done in regards to monitoring ACK RTT times on the end-node (the local load balancer) ... Over time, with more hosts, internal prefix lengths could begin to represent a fairly accurate representation of network topology (provided proper aging, etc was in place to accomodate re-routed traffic). Ugh. I guess this is going critically OT. ..kg..