AW: How to get random subset of large rrset (30+ IPs for round robin)?
d.klatt at sonnen.de
Mon Mar 23 19:35:57 UTC 2020
Von: bind-users <bind-users-bounces at lists.isc.org> im Auftrag von Warren Kumari <warren at kumari.net>
Gesendet: Freitag, 20. März 2020 18:15
Betreff: Re: How to get random subset of large rrset (30+ IPs for round robin)?
On Fri, Mar 20, 2020 at 1:04 PM Matus UHLAR - fantomas
<uhlar at fantomas.sk> wrote:
> >On Fri, Mar 20, 2020 at 3:14 AM David Klatt <d.klatt at sonnen.de> wrote:
> >> I can't find a way to do the following although I invested plenty of time
> >> in research - maybe you guys have an idea:
> >> With bind, I'd need to serve a single A record with 30+ IP addresses and
> >> these addresses have to be returned in random order round robin,
> >> which is done with:
> >> Now I'd like bind to just return a random subset of e.g. 5 IP addresses
> >> if someone requests this A record.
> On 20.03.20 10:37, Warren Kumari wrote:
> >I realize that this is the BIND list, but this sounds like an almost
> >perfect example of PowerDNS's LUA record type (or something with
> >Other than that, the only thing I can think of is BIND with DLZ and a
> >database that returns a random subset from a DB query, but that sounds
> I don't think BIND can do this at all. And I don't think it should...
> >> Reason for this are in my case some (thousands) older clients (that I can't control)
> >> that seem not being able to handle that many IPs - the OS resolver just returns an error.
> why no use IPVS-like load balancer and hide all hosts behind one or two IPs?
> that would help you much more, amongst others when any of those machines
>That's almost definitely the right answer, but there *are* cases where
>something like what the OP was asking for - 0.pool.ntp.org springs to
>mind as one example.
>But, yes, a load balancer / anycast is almost definitely going to be a
First, thanks a lot for your time and all the answers so far!
We had IPVS in front of parts of our (globally distributed) cluster in the past,
but I'd like to avoid that bottleneck and extra complexity in the future, because
application-wise the DNS round robin (random or circular doesn't matter) is
is perfectly fine for us - whenever a connection fails, the clients retries with
a different / other random server.
To get the whole picture: we are using this to distribute tens to hundreds of
thousands of openVPN connections to currently ~80 servers across the globe and
use GeoDNS (BIND ACLs with GeoIP) to send clients to their closest part
of the cluster (anycast requires owning multiple AS numbers AFAIK, which we dont have).
Whenever openVPN disconnects or a server fails, the client
takes randomly one of ten provided remote servers in the form like:
# openvpn config excerpt
remote 0.vpn.example.com 1194
remote 1.vpn.example.com 1194
remote 2.vpn.example.com 1194
remote 3.vpn.example.com 1194
remote 9.vpn.example.com 1194
So currently we already spread the IPs across these ten entries.
But as we grow, we might have more than 20 or 30 IPs per entry (the critical range
seems to start somewhere between 25 and 30, with 24 it worked at least)
I've read somewhere (sorry, can't find the page any more) that Google does it also like I wanted to do :
give out just a few (I think they do 3) random A records out of a large list of A records.
For me they wouldn't even need to be real random, it could also be cyclic, but
statistically each IP should be given out equally.
> Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> WinError #98652: Operation completed successfully.
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
bind-users at lists.isc.org
Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, Hermann Schweizer, Tim Ulbricht.
Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer 127/137/50792, USt.-IdNr. DE272208908
More information about the bind-users