On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote:
> > For example, a CDN provider can’t schedule 70% of traffic to node A
> > and 30% of traffic to node B [...] adding a “weight” attribute
>
> First, the obvious question: why reinventing RFC 2782?
Implementing this worthwhile capability can be done in four ways/places:
1) Get browsers to honour RFC 2782
2) Get resolvers and auths to support a weighted A/AAAA record (as proposed
in this thread)
3) Serve up multiple copies of the same A record, and weigh like this:
www IN A 1.2.3.4
www IN A 1.2.3.4
www IN A 10.11.12.13
And hope that record shuffling will deliver the 2:1 ratio
4) Get authoritative servers to serve A/AAAA with weighted frequency and
short TTL
Getting browsers to move is a 5 year project at least. You could get the
resolver/auth landscape moving somewhat more quickly ('we know these
people'), but it will still take a long time and support will be spotty.
The 'multiple IP address listings' thing is done in practice, but some
server remove duplicates, so it doesn't work that well.
And the last possibility is what CDNs are actually doing. It does not quite
spread out traffic perfectly, but it is good enough.
In PowerDNS Authoritative Server 4.1.1 (upcoming in January), this looks
like:
@ IN LUA A "wrandom{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Or even:
@ IN LUA A "whashed{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Which will keep the same IP address going to the same record.
--------------> [zuopeng] : so far as i know, many CDNs already use similar
methods as you mentioned in PowerDNS 4.1.1
--------------> [zuopeng] : but i think only the Authoritative Server
change is not enough, support on the recursive server is also very important .
--------------> [zuopeng] : because the resolver determines the reponse to
clients.
This is documented in https://powerdns.org/auth-4.1.1-docs/lua-records.html
- which also lists things like @ IN LUA A "closest{'1.2.3.4', '10.11.12.13'}"
which will attempt to serve up the geographically closest address.
Bert
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
