supp...@gday.ch wrote:
Hello,
we are using Global Server Loadbalancing (GSLB) for site redundancy.
GSLB is based on DNS technology and works as follows
-------------------------------
standard implementation case
-------------------------------
www.example.com. NS loadbalancer-1.example.com.
# --> ( LB located at site-a)
www.example.com. NS loadbalancer-2.example.com.
# --> ( LB located at site-b)
# the loadbalancer (LB) resolves the DNS query for www.example.com, based
# on load balancing criteria with a site specific public IP address
loadbalancer-1.example.com. A 1.y.z.w
loadbalancer-2.example.com. A 2.y.z.w
-------------------------------
?? 'CNAME approach' in question
-------------------------------
(-) Above setup works fine and for each service and we need 2 public IP
addresses one at each site hosted on the loadbalancer device.
(--) now considering that we host the same application with different names
on the same server we need for each one another 2 public IP addresses -
this leads to an unnecessary waste of addresses (x * 2)
Why would you need a separate set of load-balancer addresses?
Are you assuming, or is it a requirement of your load-balancer
implementation, that a DNS query *must* be received on the same set of
VIPs which are given as A records in the response to the query?
That seems like a silly restriction.
Your load-balancers should be able to listen for DNS queries on a single
set of IPs and then differentiate their answers -- which may be
addresses from a completely separate address pool, if the load-balancers
are multi-homed -- based on the *name* that is being queried. Assuming
that's the case, then your 2 best options are
1) delegate each site name directly to that same set of load-balancer
names, e.g.
www.example.com. NS loadbalancer-1.example.com.
www.example.com. NS loadbalancer-2.example.com.
new-www.example.com. NS loadbalancer-1.example.com.
new-www.example.com. NS loadbalancer-2.example.com.
even-newer-www.example.com NS loadbalancer-1.example.com.
even-newer-www.example.com NS loadbalancer-2.example.com.
2) alias each site name to an arbitrarily-chosen name *underneath* a
common domain which is delegated to the load-balancers, using whatever
naming conventions for those alias targets that are most
comfortable/appropriate for your environment:
us3.lb.chrysler.com. NS gssoddi1.extra.chrysler.com.
us3.lb.chrysler.com. NS gsssdci1.extra.chrysler.com.
automobility.chrysler.com. CNAME brnd-vs.us3.lb.chrysler.com.
singapore.chrysler.com. CNAME int.us3.lb.chrysler.com.
econtract.chrysler.com. CNAME cfc-ec.us3.lb.chrysler.com.
==> NEW APPROACH
Instead of using two new IP public addresses for the new service name I
defined following:
new-www.example.com CNAME www.example.com.
==> it works fine so far an the resolve process is as it should be, but
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Is it legitimate (RFC compliant) to use CNAME in this setup or is is just
luck that it works and more compliant resolvers won't work properly ??
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
It's compliant, since the target of the CNAME (www.example.com) resolves
to A records (right?), once the delegation is followed. The relevant
restriction is that you can't point a CNAME at another CNAME; that's not
the case here.
But, again, I don't fully understand your load-balancer environment.
Maybe you're struggling with some ridiculous limitation of your
load-balancer implementation, that we've never had to deal with.
If you alias all of your site names to www.example.com, and that
resolves to the same set of IP addresses, how are you going to
differentiate one set of content from another set of content? Are all of
your backend servers populated with the necessary content and vhost
definitions for all of the sites that you intend to serve? That doesn't
seem very scalable or tunable to me.
Or, is your load-balancer looking at the Host: headers of the HTTP
packets and transparently redirecting them to the correct destinations?
That seems to me rather kludgey and inefficient, and if it's got that
level of coding complexity, it should be able to differentiate via the
query QNAME and you can implement one of the more straightforward
solutions I outlined above.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
