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.