Re: multiple CNAMEs revisited

CS wrote:

>This is a testy subject, and I'm fully aware that what I want/need to
>do is not allowed.
>
>That said, I need to replicate the following "bogus" configuration:
>
>spamd IN CNAME spamd1
>spamd IN CNAME spamd1
>spamd IN CNAME spamd2
>spamd IN CNAME spamd2
>spamd IN CNAME spamd3
>spamd IN CNAME spamd4
>
>spamd1 IN A 10.0.0.1
>spamd2 IN A 10.0.0.2
>spamd3 IN A 10.0.1.1
>spamd4 IN A 10.0.1.2
>
>This hack let you work around BIND collapsing identical A records. If
>it's not obvious, I'm working with a spamassassin cluster, and spamc
>with the above dns hackery and a local copy of dnscache with the
>round-robin patch currently splits the load between two servers very
>well. And it solves the "what if a server is down" problem by just
>trying the next server in line if it doesn't get a response.
>
>root@helga[/tmp]# grep "spamd1 spamd" /var/log/spamd|wc -l
> 20872
>root@helga[/tmp]# grep "spamd2 spamd" /var/log/spamd|wc -l
> 20870
>
>I need to add two more smaller servers to this cluster, so I'd like to
>alter the weighting in DNS. Again, I understand DNS is not meant to
>solve these problems, but in this case, it could solve them very well
>if the above config was legal (or if there was a config option to
>allow the "illegal" behaviour).
>
>So given the current constraints, what is a good workaround? I've
>looked at load-balancing tools, and frankly this is a better solution;
>I don't want to rely on one piece of software; DNS in this case has a
>good deal of built-in redundancy.
>
>If this is not feasible with bind, are there any other servers I
>should be looking at?
>
This is not feasible in BIND, unless you want to hack some functionality
into the code. I hacked a $WEIGHT directive into BIND 8 a number of
years ago, but things were much simpler then, and I think I just punted
on the interaction with Dynamic Update (i.e. what happens to the
weighting if someone adds or deletes A records from the RRset?).
Nowadays, one would have to consider the interaction with DNSSEC as
well. Of course, being just a zonefile directive, this weighting
metadata is not something that would be propagated via AXFR/IXFR (an
alternate replication mechanism, such as rsync or scp, could get around
this).

I'm not sure of any other DNS software that implements this feature. I
assume you've already looked at djbdns, since you mentioned "dnscache"...


-Kevin

kcd@daimlerchrysler.com (Kevin Darcy) wrote in message news:<c91149$p73$1@FreeBSD.csie.NCTU.edu.tw>...

> I'm not sure of any other DNS software that implements this feature. I
> assume you've already looked at djbdns, since you mentioned "dnscache"...

After thinking about it some more, I started playing with tinydns. It
doesn't "collapse" multiple A records, so I put two A's in for each of
the spamd servers that I wanted to direct more traffic to. These
special case names went under a "local.domain.com" subdomain, and then
I told dnscache to look to the tinydns server running on 127.0.0.1 for
"local.domain.com". Works like a champ. It's hackish, but then again
this is only for internal use; no one outside needs to know anything
about my spamd or clamd servers.

The SRV records look interesting, but I'm not holding my breath for
spamc to be able to deal with those records.

Looking at a snippet of my logs, it does do what I'd intended:

root@helga[/tmp]# grep "helga spamd" /var/log/spamd|wc -l
15803
root@helga[/tmp]# grep "xena spamd" /var/log/spamd|wc -l
15806
root@helga[/tmp]# grep "spamd1 spamd" /var/log/spamd|wc -l
31573
root@helga[/tmp]# grep "spamd2 spamd" /var/log/spamd|wc -l
31580

That's even better than I'd hoped for, so the problem is solved.

Thanks to everyone for your input.

Charles

> -Kevin