Content Delivery Networks

Paul Reubens paulreubens11 at gmail.com
Fri Aug 10 05:55:46 UTC 2007


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 <patrick at ianai.net> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070810/a94080c7/attachment.html>


More information about the NANOG mailing list