geographic load-balancing and organizationally external secondaries

[Neil Harkins]

Hello Paul,

On Tue, 20 Dec 2005, Paul Vixie wrote:
> # Hi. There are several solutions for geographic load-balancing in DNS, 
> 
> well, there are ways of working around DNS to provide geo-load-balancing, yes.
> 
> # but all seem to require administrative ownership/non-standard
> # configuration of all the nameservers involved, which defeats the 
> # purpose of having external entities providing slave secondary service. 
> 
> that's because DNS delivers truth, not policy 
> -- fact, if you will, not value.

That difference of opinion has apparently tainted this conversation.
Note that Bind supports split-horizon configurations. That, is policy. 
 
> # However, if there were a way to prioritize/weight NS records, 
> # both requirements could be met easily. i.e. Geo-load-balancing
> # from servers you control, then fall back to external slaves
> # which have non-balanced static responses.
> 
> the mapping of the q-tuple <name,class,type> to an rrset <ttl,rdata> is meant
> to be coherent, independent of client ip address, placement on the network,
> load on any particular server, language preferred by local web browser, or
> indeed anything else except the zone's identity at the time of the query.  
> if you want noncoherence you will have to change a lot more than the format 
> and semantics of the NS rrtype.

The term "noncoherence" is your attempt to frame the debate, i.e. opinion. 
Many prefer terms like "dynamic". Both answers work. One is known to be
better, for given a client IP. 

Changing the semantics of the NS rrtype could allow queries for a zone
to be prioritized to authoritative nameservers under direct control
of the owner, over those not under direct control (slaves).

Aside from a long timeline of such a change rolling to the majority
of caching nameservers, and one use of it being tangential to something 
which some here are opposed, I fail to see why NS weighting would be 
a bad feature, by itself. 

Major ISPs could conceivably begin charging bandwidth for DNS requests 
to zones for which they provide slave service. In such an environment, 
a zoneholder would like them to be true secondaries, therefore not
incurring charges until necessary. In such a case, the DNS will tend
to be less robust until such a change is made. Given the long timeline
mentioned above, it certainly seems to me to be worth considering.

> # Any other ideas on how to accomplish this?
> 
> anycast your web server and put your incoherence at the session 
> layer where there's more room for this kind of thing.

Anycast is only as good as your BGP peering. Here's more detail: 

Akamai does what you suggest and more, providing improved http
throughput to countries that have poor connectivity. We use them,
however, it's costly (by bandwidth), and not worthwhile for known
"neighbors" to use that path. We use *stock Bind* with a split-horizon
config, giving Akamai ips to netblocks known to be poorly connected, 
otherwise our own. Akamai offers seperate DNS services, also costly.

The split-horizon config is not one easily "xferred" to a seperate
authoritative slave entity, which is ideal for failure situations. 
In a failure-of-all-primaries situation, static replies would be
acceptable, but not ideal during normal operation.

> # Has there been any other initiatives  
> # concerning weighting NS records?
> 
> yes.  tp brisco, then at rutgers, wrote a bunch of code for BIND 4 and then
> an RFC on this topic.  searching the literature would have turned up at least:
> 
> 	http://ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01260.html
> 
> and maybe also:
> 
> 	http://www.faqs.org/rfcs/rfc1794.html

Those are proposals concerning load balancing, 
not applicable for what I describe above,
and not concerning weighting of NS records.

> # I apologize if this is not the appropriate forum, 
> # but a lot of the relevant players are here,
> # thus hopefully can/will gauge validity.
> 
> i've had a lot of coffee today and i'm happy to help you with your homework.

Apparently. Thanks.

-neil