[98494] in North American Network Operators' Group
Re: Content Delivery Networks
daemon@ATHENA.MIT.EDU (Paul Reubens)
Fri Aug 10 01:57:13 2007
Date: Fri, 10 Aug 2007 01:55:46 -0400
From: "Paul Reubens" <paulreubens11@gmail.com>
To: "Patrick W.Gilmore" <patrick@ianai.net>
Cc: nanog@merit.edu
In-Reply-To: <80FA99D1-1C4B-4819-A911-7125089175CF@ianai.net>
Errors-To: owner-nanog@merit.edu
------=_Part_8112_17994316.1186725346196
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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@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
>
>
------=_Part_8112_17994316.1186725346196
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
How do you engineer around enterprise and ISP recursors that don't honor TTL, instead caching DNS records for a week or more?<br><br><br><div><span class="gmail_quote">On 8/7/07, <b class="gmail_sendername">Patrick W.Gilmore
</b> <<a href="mailto:patrick@ianai.net">patrick@ianai.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>On Aug 7, 2007, at 10:05 AM, Michal Krsek wrote:
<br><br>>>> 5) User redirection<br>>>> - You have to implement a scalable mechanisms that redirects<br>>>> users to the closes POP. You can use application redirect (fast,<br>>>> but not so much scalable), DNS redirect (scalable, but not so
<br>>>> fast) or anycasting (this needs cooperation with ISP).<br>>><br>>> What is slow about handing back different answers to the same<br>>> query via DNS, especially when they are pre-calculated? Seems
<br>>> very fast to me.<br>><br>> Yes DNS-based redirection scales very pretty.<br>><br>> But there are two problems:<br>> 1) Client may not be in same network as DNS server (I'm using my<br>> home DNS server even if I'm at IETF or I2 meeting on other side of
<br>> globe)<br><br>This has been discussed. Operational experience posted here by Owen<br>shows < 10% of users are "far" from their recursive NS.<br><br>You are the tiny minority. (Don't feel bad, so am I. :) Most
<br>"users" either use the NS handed out by their local DHCP server, or<br>they are VPN'ing anyway.<br><br><br>> 2) DNS TTL makes realtime traffic management inpossible. Remember<br>> you may not distribute network traffic, but sometimes also server
<br>> load. If one server/POP fails or is overloaded, you need to<br>> redirect users to another one in realtime.<br><br>Define "real time"? To do it in 1 second or less is nigh<br>impossible. But I challenge you to fail anything over in 1 second
<br>when IP communication with end users not on your LAN is involved.<br><br>I've seen TTLs as low as 20s, giving you a mean fail-over time of 10<br>seconds. That's more than fast enough for most applications these days.
<br><br>--<br>TTFN,<br>patrick<br><br></blockquote></div><br>
------=_Part_8112_17994316.1186725346196--
