Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

["[e-mail]" <[e-mail]>]

thanks for your comments!

According to my understanding, here are 2 main differences between RFC2782 and this idea :

(1) RFC2782 does not solve the problem of using multi-CDN  (multiple CNAME cannot coexist);
    here we can use multipile weighted CNMAEXs (need to coexist with CNAME) to accomplish this;
    besides, weighted CNAMEXs can control traffic ratio among several CDN providers;

(2) RFC2782 requires browser's support;
    Using this method, a browser has no idea about weighted AX/AAAAXs. 
    It requires no change of browsers.



[e-mail]
 
From: bert hubert
Date: 2017-12-13 16:43
To: Stephane Bortzmeyer
CC: [e-mail]; dnsop
Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
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.
 
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