The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."
Hrmm, no, that is called "Akamai", isn't it? :-) ... still collecting Heirloom-Quality Specimens of Pre-Owned Mirror-Image Cache Routers for our Museum of Internet Treasures, drop us a line if you still have any available.... Mary Grace mary@ms.edu At 01:20 PM 10/6/01 -0700, you wrote:
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive
performance,
or any other criteria, then the name for this is: "broken."
On Sat, 06 Oct 2001 16:44:57 EDT, Mary Grace said:
Hrmm, no, that is called "Akamai", isn't it? :)
There's an Akamai across the hall from my office, and the way it was explained to *me* was that the DNS always returns the same IP address for a given Akamai'zed page (so the URLs in the HTML are consistent), but routing games are used to direct the packets to the appropriate server. In other words, it's one IP that points to disparate machines. Valdis Kletnieks Operating Systems Analyst Virginia Tech
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks@vt.edu Sent: October 7, 2001 1:05 AM To: Mary Grace Cc: nanog@merit.edu Subject: Re: dns based loadbalancing/failover
On Sat, 06 Oct 2001 16:44:57 EDT, Mary Grace said:
Hrmm, no, that is called "Akamai", isn't it? :)
There's an Akamai across the hall from my office, and the way it was explained to *me* was that the DNS always returns the same IP address for a given Akamai'zed page (so the URLs in the HTML are consistent), but routing games are used to direct the packets to the appropriate server. In other words, it's one IP that points to disparate machines.
They lied to you (I don't remember who a96.g.akamai is; it's some well-known Akamai customer, maybe CNN): vivienm@quartz:~$ nslookup a96.g.akamai.net Server: quartz.bos.dyndns.org Address: 66.37.218.198 Non-authoritative answer: Name: a96.g.akamai.net Addresses: 216.32.119.10, 216.32.119.74 vivienm@quartz:~$ nslookup a96.g.akamai.net amethyst.ith.dyndns.org Server: amethyst.ith.dyndns.org Address: 216.7.11.130 Non-authoritative answer: Name: a96.g.akamai.net Addresses: 207.127.111.70, 207.127.111.73 vivienm@nickel:~$ nslookup a96.g.akamai.net Server: zinc.fmt.dyndns.org Address: 64.71.191.27 Non-authoritative answer: Name: a96.g.akamai.net Addresses: 64.21.49.15, 64.21.49.36 vivienm@lapis:~$ nslookup a96.g.akamai.net Server: 212.100.224.10 Address: 212.100.224.10#53 Name: a96.g.akamai.net Address: 64.124.157.126 Name: a96.g.akamai.net Address: 64.124.157.91 [from my home box] vivienm@deep:~$ nslookup a96.g.akamai.net Server: proxy1.slnt1.on.wave.home.com Address: 24.112.33.4 Name: a96.g.akamai.net Addresses: 65.163.234.8, 65.163.234.24 [from one of your DNS servers] vivienm@quartz:~$ nslookup a96.g.akamai.net milo.cns.vt.edu Server: milo.cns.vt.edu Address: 198.82.247.98 Name: a96.g.akamai.net Addresses: 198.82.164.48, 198.82.164.40 I'm sure I could keep going if you really wanted, but I think that's enough to prove the point... Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Akamai hostnames do not map to specific customers; that information is part of the metadata that follows the hostname. Obviously, the customer ID and the source server must match or else no cachey cachey. :) The number in the hostname figures into Akamai's load balancing algorithm, IIRC. What actually happens is a type of "mapping" that tries to nail down the network location of the source IP that's on the DNS query, and returns the IP of the cache server that's hopefully closest to that source IP. Most of the time this works well, although it's not extremely precise; the most obvious caveat is that the source IP recorded is that of the DNS resolver, not the HTTP client. If your workstation on UUNet in Washington is configured to query a name server that's on, say, Level3's network in Seattle, Akamai's servers will use the latter location for this evaluation, with the obvious sub-optimal result. But the majority of the time, it delivers the IP of a machine that's closer to the end user than the customer's server. And the customer gets the benefit of reduced outbound traffic and server load in any case. It's particularly effective at my office, as my workstation is 4ms away from the Akamai server in our local data center. But my home DSL service, for which the other end of the PVC lives at the same site, is served by an Akamai server in Philadelphia. Go figure. -Chris On Sun, Oct 07, 2001 at 01:14:24AM -0400, Vivien M. wrote:
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks@vt.edu Sent: October 7, 2001 1:05 AM To: Mary Grace Cc: nanog@merit.edu Subject: Re: dns based loadbalancing/failover
On Sat, 06 Oct 2001 16:44:57 EDT, Mary Grace said:
Hrmm, no, that is called "Akamai", isn't it? :)
There's an Akamai across the hall from my office, and the way it was explained to *me* was that the DNS always returns the same IP address for a given Akamai'zed page (so the URLs in the HTML are consistent), but routing games are used to direct the packets to the appropriate server. In other words, it's one IP that points to disparate machines.
They lied to you (I don't remember who a96.g.akamai is; it's some well-known Akamai customer, maybe CNN): vivienm@quartz:~$ nslookup a96.g.akamai.net Server: quartz.bos.dyndns.org Address: 66.37.218.198
Non-authoritative answer: Name: a96.g.akamai.net Addresses: 216.32.119.10, 216.32.119.74
vivienm@quartz:~$ nslookup a96.g.akamai.net amethyst.ith.dyndns.org Server: amethyst.ith.dyndns.org Address: 216.7.11.130
Non-authoritative answer: Name: a96.g.akamai.net Addresses: 207.127.111.70, 207.127.111.73
vivienm@nickel:~$ nslookup a96.g.akamai.net Server: zinc.fmt.dyndns.org Address: 64.71.191.27
Non-authoritative answer: Name: a96.g.akamai.net Addresses: 64.21.49.15, 64.21.49.36
vivienm@lapis:~$ nslookup a96.g.akamai.net Server: 212.100.224.10 Address: 212.100.224.10#53
Name: a96.g.akamai.net Address: 64.124.157.126 Name: a96.g.akamai.net Address: 64.124.157.91
[from my home box]
vivienm@deep:~$ nslookup a96.g.akamai.net Server: proxy1.slnt1.on.wave.home.com Address: 24.112.33.4
Name: a96.g.akamai.net Addresses: 65.163.234.8, 65.163.234.24
[from one of your DNS servers] vivienm@quartz:~$ nslookup a96.g.akamai.net milo.cns.vt.edu Server: milo.cns.vt.edu Address: 198.82.247.98
Name: a96.g.akamai.net Addresses: 198.82.164.48, 198.82.164.40
I'm sure I could keep going if you really wanted, but I think that's enough to prove the point...
Vivien
-- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On 6 Oct 2001, Paul Vixie wrote:
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."
Better tell that to those that have built successful businesses on what you call "broken."
On Sat, Oct 06, 2001 at 01:20:27PM -0700, Paul Vixie wrote:
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."
Be aware that this is not my business model, by the way. Most people wanting 'global server load balancing' appear to buy Alteon Acedirectors. Is 'behaviour not intended by the original rfc' your definition or 'broken'? Many important features of today's internet violate at least the spritit of previous standards, but are able to ride piggyback. But the main question is, if this is "broken.", please elaborate what exactly "breaks." Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services Trilab The Technology People Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
On Sat, Oct 06, 2001 at 01:20:27PM -0700, Paul Vixie wrote:
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."
I suppose you don't do split-horizon DNS, then? Greetz, Peter -- Monopoly http://www.dataloss.nl/monopoly.html
On Sat, Oct 06, 2001 at 01:20:27PM -0700, Paul Vixie wrote:
The really neat thing is that you can do this with any nameserver. Install N nameservers and connect each of them to one of your ISPs. These nameservers are all masters, and all contain different data.
If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."
There obviously is a need for an 'official' method to do global load balancing using DNS. Let's face it, people are doing it now on a not so large scale but that is rapidly changing because of the introduction of both hardware and software solutions that (mis)use DNS to overcome it's current limitation. I'm not very interested in the discussion why this behaviour would be broken. It's for more interesting to talk about improving DNS so that there will be room for things like load balancing or dynamic DNS. In such a way that people will not start screaming when they see TTLs of 30 seconds or non-linear behaviour of load balancers. Regards, Stefan
Date: Sun, 7 Oct 2001 02:14:27 +0200 From: Stefan Arentz <stefan.arentz@soze.com>
[ snip ]
I'm not very interested in the discussion why this behaviour would be broken. It's for more interesting to talk about improving DNS so that there will be room for things like load balancing or dynamic DNS. In such a way that people will not start screaming when they see TTLs of 30 seconds or non-linear behaviour of load balancers.
Note: "Context-defined new terms" in double quotes How probable would a different A RR be on the "next" query? Perhaps we should look at BGP or other link state protocols as a starting point... a failover-ready NS could negotiate "I tell you when the A RR changes iff it happens within TTL[1]" behavior with the far end -- useful for failover, but not load-balancing. Of course, because DNS traffic is multihop, endpoint authentication is more of an issue than with BGP. [1] Not necessarily the same TTL as current DNS uses Of course, the drawback with this approach is deployment: Look at the reluctance of MCSE monkeys and |<0b4lt |<1dd13z^W^W^W^W^W some net admins to patch critical bugs. Do you think that they'll upgrade things at the edge to support a non-critical cool new feature? Not likely. The onus for correct operation is on the hosting provider. Are we talking about dynamic balancing within a single site, or across multiple locations? If the former, why not use gear a la Extreme, thus 1) conserving IP space and 2) remaining transparent to the outside world? If distributing across multiple sites, one can use BGP to advert the same subnet from different points... let routing protocols route, and DNS give the same answer all the time. (Damn those filters!) Ideally, the routing protocols could shunt "excess traffic" from a "heavily loaded" site to a "lightly loaded" one. Load balancing across multiple sites gets uglier. Either we have incredibly short TTLs (sorry, AOL users[2]) or we need something else. Perhaps storing multiple routes (woops, more route memory) and use some sort of ECN? [2] I personally find it tempting to say, 'screw anyone who uses looong TTLs with flagrant disregard to the authoritative host's wishes'... allowing bad behavior to become a de facto standard by virtue of customer base is _not_ sound engineering. All-pairs-shortest-paths gives nice info... until you look at scalability, or the lack thereof. O(N^4) cpu time[3] and a few times as much RAM? Ughh. [3] IIRC, O(N^3 * log(N)) is do-able. However, standard APSP does not record paths... only path lengths. Minus two points for chewing up even more CPU. I guess that the big questions would be: 1. How often do changes occur? 2. How sparse are "rapidly changing" values wrt the entire graph? 3. Distribution across multiple sites? 4. What do we leave up to DNS? 5. What do we leave up to routing? If heavily enough distributed, congestion should be highly localized... if present at all. Let's assume that a "basic server" can service 10 Mbps of traffic. Install servers in various points, a la Akamai... any traffic sinks here ever manage to overload your Akamai boxen? If so, how often compared to a random traffic source. Whatever we do, we must keep state as far from the core as possible. State in core baaad. I've rambled enough. CTRL+X with no further edits. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (10)
-
bert hubert -
Christopher A. Woodfield -
E.B. Dreger -
Mary Grace -
Patrick Greenwell -
Paul Vixie -
Peter van Dijk -
Stefan Arentz -
Valdis.Kletnieks＠vt.edu -
Vivien M.