How do you engineer around enterprise and ISP recursors that don't honor TTL, instead caching DNS records for a week or more?
On 8/7/07, Patrick W.Gilmore <[EMAIL PROTECTED]> wrote: > > > On Aug 7, 2007, at 10:05 AM, Michal Krsek wrote: > > >>> 5) User redirection > >>> - You have to implement a scalable mechanisms that redirects > >>> users to the closes POP. You can use application redirect (fast, > >>> but not so much scalable), DNS redirect (scalable, but not so > >>> fast) or anycasting (this needs cooperation with ISP). > >> > >> What is slow about handing back different answers to the same > >> query via DNS, especially when they are pre-calculated? Seems > >> very fast to me. > > > > Yes DNS-based redirection scales very pretty. > > > > But there are two problems: > > 1) Client may not be in same network as DNS server (I'm using my > > home DNS server even if I'm at IETF or I2 meeting on other side of > > globe) > > This has been discussed. Operational experience posted here by Owen > shows < 10% of users are "far" from their recursive NS. > > You are the tiny minority. (Don't feel bad, so am I. :) Most > "users" either use the NS handed out by their local DHCP server, or > they are VPN'ing anyway. > > > > 2) DNS TTL makes realtime traffic management inpossible. Remember > > you may not distribute network traffic, but sometimes also server > > load. If one server/POP fails or is overloaded, you need to > > redirect users to another one in realtime. > > Define "real time"? To do it in 1 second or less is nigh > impossible. But I challenge you to fail anything over in 1 second > when IP communication with end users not on your LAN is involved. > > I've seen TTLs as low as 20s, giving you a mean fail-over time of 10 > seconds. That's more than fast enough for most applications these days. > > -- > TTFN, > patrick > >