Round robin on CNAME
Someone
Hello,
I would like to know if it's possible to do round robin based on
multiple CNAME entries, like that for example: ?
www1
IN A X.X.X.X
www2
IN A X.X.X.X
www
IN CNAME www1
www
IN CNAME www2
Because my BIND v9 is complaining:
Mar 27 09:41:02 hostname named[22042]: dns_master_load:
master/filename:12: multiple RRs of singleton type
Or else how can I achieve this ? Because I would like to do round-robin
between 2 web servers but still have valid names to access and
differentiate them like www1 and www2.
Thanks for your comments
Regards
Michael Kjorling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Someone,
CNAME, or "canonical name" records, point one node in the DNS tree at
exactly one other node. If you want to have the name "www" resolve to
two different addresses, you can use A or AAAA/A6 records instead:
> www A 10.0.0.1
> www A 192.168.0.1
Of course you can still define other records which carry the same
address data:
> www1 A 10.0.0.1
> www2 A 192.168.0.1
Michael Kjörling
- --
Michael Kjörling -- Programmer/Network administrator ^..^
Internet: mic...@kjorling.com -- FidoNet: 2:204/254.4 \/
PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e
``And indeed people sometimes speak of man's "bestial" cruelty, but
this is very unfair and insulting to the beasts: a beast can never be
so cruel as a man, so ingeniously, so artistically cruel.''
(Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Public key is at http://michael.kjorling.com/contact/pgp.html
iD8DBQE8oeY5KqN7/Ypw4z4RAv7VAJ4zBm00ITQDJAlX5KPdXcHOhPIiEwCgmawT
+fvisdo7Z4GZrBbe4xXHJZg=
=a8UK
-----END PGP SIGNATURE-----
Barry Margolin
>
>Hello,
>
>I would like to know if it's possible to do round robin based on
>multiple CNAME entries, like that for example: ?
No.
>www1
> IN A X.X.X.X
>www2
> IN A X.X.X.X
>www
> IN CNAME www1
>www
> IN CNAME www2
>
>Because my BIND v9 is complaining:
>
>Mar 27 09:41:02 hostname named[22042]: dns_master_load:
>master/filename:12: multiple RRs of singleton type
"RRS of singleton type" means you're only allowed to have one record of
that type (CNAME) for a particular name.
>Or else how can I achieve this ? Because I would like to do round-robin
>between 2 web servers but still have valid names to access and
>differentiate them like www1 and www2.
www1 IN A X.X.X.X
www2 IN A Y.Y.Y.Y
www IN A X.X.X.X
IN A Y.Y.Y.Y
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
p...@icke-reklam.ipsec.nu
Someone <ple...@nospam.net> wrote:
> Hello,
> I would like to know if it's possible to do round robin based on
> multiple CNAME entries, like that for example: ?
You cannot legally do this. It's an error to have several
CNAMES for the same lhand.
> www1
> IN A X.X.X.X
> www2
> IN A X.X.X.X
> www
> IN CNAME www1
> www
> IN CNAME www2
> Because my BIND v9 is complaining:
> Mar 27 09:41:02 hostname named[22042]: dns_master_load:
> master/filename:12: multiple RRs of singleton type
> Or else how can I achieve this ? Because I would like to do round-robin
> between 2 web servers but still have valid names to access and
> differentiate them like www1 and www2.
You will have to use A records ( or make the transition to SRV records that
will actually do what you want )
> Thanks for your comments
> Regards
--
Peter Håkanson
IPSec Sverige (At the Riverside of Gothenburg, home of Volvo)
Sorry about my e-mail address, but i'm trying to keep spam out.
Remove "icke-reklam" and it works.
Michael Kjorling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The problem with SRV records is that very few clients so far make use
of them at all. So that might not be a workable route, especially
given that the clients are most likely using standard web browsers.
Multiple A records is the route I would take to solving this problem
at least.
Michael Kjörling
On Mar 27 2002 18:30 -0000, p...@icke-reklam.ipsec.nu wrote:
> You will have to use A records ( or make the transition to SRV records that
> will actually do what you want )
- --
Michael Kjörling -- Programmer/Network administrator ^..^
Internet: mic...@kjorling.com -- FidoNet: 2:204/254.4 \/
PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e
``And indeed people sometimes speak of man's "bestial" cruelty, but
this is very unfair and insulting to the beasts: a beast can never be
so cruel as a man, so ingeniously, so artistically cruel.''
(Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Public key is at http://michael.kjorling.com/contact/pgp.html
iD8DBQE8ohGiKqN7/Ypw4z4RAgw5AJ9tsDn0/mwEHZo165evjyGECcO61QCg5Whk
jJhi+Y726TsQ+nl/TUmV8EI=
=P9N9
-----END PGP SIGNATURE-----
p...@icke-reklam.ipsec.nu
Michael Kjorling <mic...@kjorling.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> The problem with SRV records is that very few clients so far make use
> of them at all. So that might not be a workable route, especially
> given that the clients are most likely using standard web browsers.
I have been active with conqueror and SRV. And who knows, some day
it's availabel in a store close to your home :-)
> Multiple A records is the route I would take to solving this problem
> at least.
Yes, as a temporary thing. SRV _is_ the way to go. Just swich browser !
> Michael Kjörling
> On Mar 27 2002 18:30 -0000, p...@icke-reklam.ipsec.nu wrote:
>> You will have to use A records ( or make the transition to SRV records that
>> will actually do what you want )
> - --
> Michael Kjörling -- Programmer/Network administrator ^..^
> Internet: mic...@kjorling.com -- FidoNet: 2:204/254.4 \/
> PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e
> ``And indeed people sometimes speak of man's "bestial" cruelty, but
> this is very unfair and insulting to the beasts: a beast can never be
> so cruel as a man, so ingeniously, so artistically cruel.''
> (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov')
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Public key is at http://michael.kjorling.com/contact/pgp.html
> iD8DBQE8ohGiKqN7/Ypw4z4RAgw5AJ9tsDn0/mwEHZo165evjyGECcO61QCg5Whk
> jJhi+Y726TsQ+nl/TUmV8EI=
> =P9N9
> -----END PGP SIGNATURE-----
Barry Margolin
Peter Peters <peter....@civ.utwente.nl> wrote:
>
>On 27 Mar 2002 07:44:25 -0800, Barry Margolin <bar...@genuity.net>
>wrote:
>
>>www1 IN A X.X.X.X
>>www2 IN A Y.Y.Y.Y
>>www IN A X.X.X.X
>> IN A Y.Y.Y.Y
>
>y.y.y.y.in-addr.arpa IN PTR www
>x.x.x.x.in-addr.arpa IN PTR www
I would recommend having the PTR records point to www1 and www2, not www.
That way, if there's ever any outgoing messages from the servers and the
source is logged, you're ensured that it will log the specific name rather
than the generic name.
>for those wanting to reverse check IP-information. Esp. with
>certificates.
I don't know much about how certificates work, so I can't comment on
whether this is true.
glen herrmannsfeldt
>On 27 Mar 2002 07:44:25 -0800, Barry Margolin <bar...@genuity.net>
>wrote:
>>www1 IN A X.X.X.X
>>www2 IN A Y.Y.Y.Y
>>www IN A X.X.X.X
>> IN A Y.Y.Y.Y
>And do
>y.y.y.y.in-addr.arpa IN PTR www
>x.x.x.x.in-addr.arpa IN PTR www
>for those wanting to reverse check IP-information. Esp. with
>certificates.
As far as I know, this isn't necessary. The reverse lookup
is verified by a forward lookup, so:
y.y.y.y.in-addr.arpa IN PTR www2
x.x.x.x.in-addr.arpa IN PTR www1
will work fine.
(This used to be true. If it changed recently I would like
to know about it.)
-- glen
William Stacey
www.yahoo.com. 1511 IN CNAME www.yahoo.akadns.net.
www.yahoo.akadns.net. 287 IN A 64.58.76.178
www.yahoo.akadns.net. 287 IN A 64.58.76.223
www.yahoo.akadns.net. 287 IN A 64.58.76.222
...
--
William Stacey, MCSE
Microsoft MVP Windows 2000/NT Server
"Someone" <ple...@nospam.net> wrote in message
news:a7somv$h...@pub3.rc.vix.com...
Nate Campi
On Sat, Mar 30, 2002 at 09:27:32PM -0500, William Stacey wrote:
> Here is how people like Yahoo and MS do it:
> www.yahoo.com. 1511 IN CNAME www.yahoo.akadns.net.
> www.yahoo.akadns.net. 287 IN A 64.58.76.178
> www.yahoo.akadns.net. 287 IN A 64.58.76.223
> www.yahoo.akadns.net. 287 IN A 64.58.76.222
www.lycos.com is done this way, too. The reason for the CNAME is to get
a DNS service (from Akamai in this case) that gives out different
addresses depending on:
- where the querier is asking from (get a "closer" web cluster)
- the condition of the different web clusters that serve the site
- the condition of the network between the querier and the different
clusters that serve the site
- whether or not a test object is live on each of the clusters that
serve the site
- probably more that I can't think of at midnight
This has no relation to "multiple CNAME" entries, but what Akamai calls
"DNS Geo Load Balancing", if I remember the term correctly.
The experts on this list undoubtedly noticed that Akamai uses a CNAME
instead of simply delegating the domain name. I'm supposed to talk to
the Akamai PD people this week to explain how delegation is more
efficient. We'll see if they listen. If you're going to do it, you may
as well do it right.
--
Nate
Linux is like an indian's tent:
No gates, no windows, and apache inside.
Nate Campi
On Sun, Mar 31, 2002 at 12:09:27AM -0800, Nate Campi wrote:
>
> On Sat, Mar 30, 2002 at 09:27:32PM -0500, William Stacey wrote:
> - probably more that I can't think of at midnight
Speaking of DNS late at night - once I was moving a HUGE web site that
gives out free web pages (think camera stand with three legs) and I set
the NS records to "howtired.com" instead of "hotwired.com".
It was 2am when I made that change - how fitting ;)
--
Nate
Yea, tho I walk thru the valley of the shadow of clues, I shall fear
no luser, for Thou lart with me, Thy chicken and Thy manual, they
comfort me.
William Stacey
> instead of simply delegating the domain name. I'm supposed to talk to
> the Akamai PD people this week to explain how delegation is more
> efficient.
Could you expand on that here too that we may also benefit?
Cheers!
Nate Campi
On Sun, Mar 31, 2002 at 11:09:33AM -0500, William Stacey wrote:
> > The experts on this list undoubtedly noticed that Akamai uses a CNAME
> > instead of simply delegating the domain name. I'm supposed to talk to
> > the Akamai PD people this week to explain how delegation is more
> > efficient.
>
It's a small difference, but we're dealing with really busy domain names
here, and small differences matter. When a CNAME is encountered, the
query has to be rewritten with the new name. This costs in computing
resources, adding latency. Following NS records without rewriting the
query would be better.
Ideally, I could give the akadns nameservers names inside the lycos.com
domain, and I could delegate "in bailiwick", and provide the IPs as glue.
This would be extremely efficient and fast. This is what I'll actually
push for.
Like Bill W's program says, "Half measures availed us nothing."
--
Nate
"If all else fails, read the documentation."
William Stacey
;; ANSWER SECTION:
www.lycos.com. 900 IN CNAME www.lycos.com.akadns.net.
;; AUTHORITY SECTION:
. 237077 IN NS I.ROOT-SERVERS.net.
. 237077 IN NS J.ROOT-SERVERS.net.
<snip>
it would return same CNAME RR, but instead of root Authority it would
return?:
;; ANSWER SECTION:
lycos.com.akadns.net. 88575 IN NS zc.akadns.net.
lycos.com.akadns.net. 88575 IN NS zf.akadns.net.
lycos.com.akadns.net. 88575 IN NS zb.akadns.net.
...
;; ADDITIONAL SECTION:
zc.akadns.net. 103172 IN A 63.241.199.50
zf.akadns.net. 103172 IN A 63.215.198.79
...
How would the lycos.com zone look to achieve this? Wouldn't this involve
out of zone data? Assuming no caching, the savings is root, net, akadns,
com (i.e. net of 4 iterations) ?
-- wjs
"Nate Campi" <na...@campin.net> wrote in message
news:a87l4h$b...@pub3.rc.vix.com...
Jim Reid
Nate> It's a small difference, but we're dealing with really busy
Nate> domain names here, and small differences matter. When a
Nate> CNAME is encountered, the query has to be rewritten with the
Nate> new name. This costs in computing resources, adding
Nate> latency. Following NS records without rewriting the query
Nate> would be better.
Frankly, this does not appear to be well thought out. Have you
actually done an analysis to support or justify this argument? It
would be interesting to see some numbers which compares both
approaches.
First of all, when a server encounters a zone cut it has to resolve
the names of the delegation's NS records. So it's probably going to
have the "overhead" of rewriting a few queries to lookup the names of
the NS records. Secondly, there could be additional latency while the
server establishes the RTTs to the servers for the delegated zone. And
let's assume none of those servers are ever unreachable.... Thirdly,
the overhead of rewriting a query is negligible: much less than a
millisecond on today's hardware. BIND9 running on a 700 Mhz Pentium
can pump out around 2000 *answers* a second: another implementation
does ~25,000 answers a second on the same box. Formatting an answer
has more overhead than rewriting a query because an answer tends to
have many more RRs than a query. Finally, there's caching to consider.
After the delays for latency and the "overhead" of rewriting that
initial query, subsequent lookups will use what's in the cache anyway.
So any small difference is unlikely to matter at all. You may well
find that your optimisation -- if it even is that -- speeds up one
query in a few thousand by a fraction of a millisecond. I doubt this
improvement is even detectable. It may well be obscured by the noise
of minor variations in the packet switching rate of a router or
switch.
Barry Margolin
>
>On Sun, Mar 31, 2002 at 11:09:33AM -0500, William Stacey wrote:
>> > The experts on this list undoubtedly noticed that Akamai uses a CNAME
>> > instead of simply delegating the domain name. I'm supposed to talk to
>> > the Akamai PD people this week to explain how delegation is more
>> > efficient.
>>
>> Could you expand on that here too that we may also benefit?
>
>It's a small difference, but we're dealing with really busy domain names
>here, and small differences matter. When a CNAME is encountered, the
>query has to be rewritten with the new name. This costs in computing
>resources, adding latency. Following NS records without rewriting the
>query would be better.
I don't think it makes much difference. Whichever type of record is used
will be cached, and then your server will go directly to the Akamai
nameserver.
The CNAME technique simplifies adding new names pointing to the same Akamai
webserver. The customer adds a CNAME record to his DNS (pointing to the
same <something>.akadns.net name), Akamai adds the name to the virtual host
configuration of the webserver, and nothing needs to be done on the Akamai
nameserver. NS delegation would require a third step of adding the
subdomain to the Akamai nameservers, and every additional step means one
more thing that can go wrong (remember the KISS principle).
Nate Campi
On Mon, Apr 01, 2002 at 09:59:47AM +0100, Jim Reid wrote:
> >>>>> "Nate" == Nate Campi <na...@campin.net> writes:
>
> Nate> It's a small difference, but we're dealing with really busy
> Nate> domain names here, and small differences matter. When a
> Nate> CNAME is encountered, the query has to be rewritten with the
> Nate> new name. This costs in computing resources, adding
> Nate> latency. Following NS records without rewriting the query
> Nate> would be better.
>
> Frankly, this does not appear to be well thought out. Have you
> actually done an analysis to support or justify this argument? It
> would be interesting to see some numbers which compares both
> approaches.
Boy it's amazing how Jim ignores statements like "It's a small
difference".
> First of all, when a server encounters a zone cut it has to resolve
> the names of the delegation's NS records. So it's probably going to
> have the "overhead" of rewriting a few queries to lookup the names of
> the NS records.
Pay attention Jim. NS records provided as glue inside the lycos.com
zone.
<snip the rest of the stuff that supports Nate's statement that "It's a
small difference">
--
Nate
"Whom computers would destroy, they must first drive mad." -Anon.
Nate Campi
On Sun, Mar 31, 2002 at 10:48:48PM -0500, William Stacey wrote:
> You mean instead of ns1.hotwired.com returning following:
> ;; ANSWER SECTION:
> www.lycos.com. 900 IN CNAME www.lycos.com.akadns.net.
>
> ;; AUTHORITY SECTION:
> . 237077 IN NS I.ROOT-SERVERS.net.
> . 237077 IN NS J.ROOT-SERVERS.net.
> <snip>
>
> it would return same CNAME RR, but instead of root Authority it would
> return?:
> ;; ANSWER SECTION:
> lycos.com.akadns.net. 88575 IN NS zc.akadns.net.
> lycos.com.akadns.net. 88575 IN NS zf.akadns.net.
> lycos.com.akadns.net. 88575 IN NS zb.akadns.net.
> ...
> ;; ADDITIONAL SECTION:
> zc.akadns.net. 103172 IN A 63.241.199.50
> zf.akadns.net. 103172 IN A 63.215.198.79
> ...
>
> How would the lycos.com zone look to achieve this? Wouldn't this involve
> out of zone data? Assuming no caching, the savings is root, net, akadns,
> com (i.e. net of 4 iterations) ?
You would get:
;; ANSWER SECTION:
www.lycos.com. 3600 IN NS a.akadns.lycos.com.
;; ADDITIONAL SECTION:
a.akadns.lycos.com. 3600 IN A 63.241.199.50
Now remote resolvers can go straight to 63.241.199.50 (and whatever
other nameservers have the delegation done to) and ask for
www.lycos.com.
Nate Campi
On Mon, Apr 01, 2002 at 09:59:47AM +0100, Jim Reid wrote:
> >>>>> "Nate" == Nate Campi <na...@campin.net> writes:
>
> Nate> It's a small difference, but we're dealing with really busy
> Nate> domain names here, and small differences matter. When a
> Nate> CNAME is encountered, the query has to be rewritten with the
> Nate> new name. This costs in computing resources, adding
> Nate> latency. Following NS records without rewriting the query
> Nate> would be better.
>
> Frankly, this does not appear to be well thought out. Have you
> actually done an analysis to support or justify this argument? It
> would be interesting to see some numbers which compares both
> approaches.
There's no measurement needed. If I hand out a name for a nameserver
inside the lycos.com zone, remote resolvers head right for those IPs.
This is far more efficient not only because there's no query rewriting
(small amount of latency, we all agree), but also no resolution of the
right side of the NS records. The IPs are provided as glue. There could
be all kinds of latency resolving those, none of which is needed for an
in-bailiwick delegation.
Do you still think it needs to be measured after explained this way? Do
you not agree this is better?
--
Nate
During the million-dollar BIND 9 rewrite, Paul Vixie characterized the
original BIND code as 'sleazeware produced in a drunken fury by a bunch
of U C Berkeley grad students.'
-- D.J. Bernstein http://cr.yp.to/djbdns/blurb/unbind.html
Barry Margolin
>
>On Mon, Apr 01, 2002 at 09:59:47AM +0100, Jim Reid wrote:
>> >>>>> "Nate" == Nate Campi <na...@campin.net> writes:
>>
>> Nate> It's a small difference, but we're dealing with really busy
>> Nate> domain names here, and small differences matter. When a
>> Nate> CNAME is encountered, the query has to be rewritten with the
>> Nate> new name. This costs in computing resources, adding
>> Nate> latency. Following NS records without rewriting the query
>> Nate> would be better.
>>
>> Frankly, this does not appear to be well thought out. Have you
>> actually done an analysis to support or justify this argument? It
>> would be interesting to see some numbers which compares both
>> approaches.
>
>There's no measurement needed. If I hand out a name for a nameserver
>inside the lycos.com zone, remote resolvers head right for those IPs.
But since they're actually Akamai's nameservers, how are you planning on
keeping the A records correct as Akamai adds and removes nameservers around
the world?
Jim Reid
Nate> It's a small difference, but we're dealing with really busy
Nate> domain names here, and small differences matter. When a
Nate> CNAME is encountered, the query has to be rewritten with the
Nate> new name. This costs in computing resources, adding
Nate> latency. Following NS records without rewriting the query
Nate> would be better.
>> Frankly, this does not appear to be well thought out. Have you
>> actually done an analysis to support or justify this argument?
>> It would be interesting to see some numbers which compares both
>> approaches.
Nate> Boy it's amazing how Jim ignores statements like "It's a
Nate> small difference".
I didn't. Clearly your definition of "small" is not the same as mine.
You said these "small differences matter". I gave a bunch of reasons
why your reasoning was suspect (let's be charitable) and any small
difference would be so tiny it would probably be invisible, assuming
it could even be measured reliably. If that's true then your small
difference simply does not matter.
Now I did ask you if you had any numbers or analysis to support your
claim. Where are they? If you can provide this, I'll be happy to look
at your methodology and results. And if they show you're correct and
I'm not, I'll say so in public. Fair enough?
Nate Campi
On Mon, Apr 01, 2002 at 07:43:08PM +0000, Barry Margolin wrote:
> In article <a8acu2$b...@pub3.rc.vix.com>, Nate Campi <na...@campin.net> wrote:
> >
> >> >>>>> "Nate" == Nate Campi <na...@campin.net> writes:
> >>
> >> Nate> It's a small difference, but we're dealing with really busy
> >> Nate> domain names here, and small differences matter. When a
> >> Nate> CNAME is encountered, the query has to be rewritten with the
> >> Nate> new name. This costs in computing resources, adding
> >> Nate> latency. Following NS records without rewriting the query
> >> Nate> would be better.
> >>
> >> Frankly, this does not appear to be well thought out. Have you
> >> actually done an analysis to support or justify this argument? It
> >> would be interesting to see some numbers which compares both
> >> approaches.
> >
> >There's no measurement needed. If I hand out a name for a nameserver
> >inside the lycos.com zone, remote resolvers head right for those IPs.
>
> keeping the A records correct as Akamai adds and removes nameservers around
> the world?
That's what I need to talk to them about. This likely isn't an issue,
though, since they don't move IPs. They have a single IP that bounces
around to different hosts inside their network depending on conditions.
--
Nate
I wanted to read your article but it had a bunch of HTML code and
brackets and garbage, instead of content. Maybe you could try posting
it again? - Al Iverson <ne...@radparker.com>
Nate Campi
On Mon, Apr 01, 2002 at 08:44:22PM +0100, Jim Reid wrote:
> >>>>> "Nate" == Nate Campi <na...@campin.net> writes:
>
> Nate> It's a small difference, but we're dealing with really busy
> Nate> domain names here, and small differences matter. When a
> Nate> CNAME is encountered, the query has to be rewritten with the
> Nate> new name. This costs in computing resources, adding
> Nate> latency. Following NS records without rewriting the query
> Nate> would be better.
> >> Frankly, this does not appear to be well thought out. Have you
> >> actually done an analysis to support or justify this argument?
> >> It would be interesting to see some numbers which compares both
> >> approaches.
>
> Nate> small difference".
>
> I didn't. Clearly your definition of "small" is not the same as mine.
> You said these "small differences matter". I gave a bunch of reasons
> why your reasoning was suspect (let's be charitable) and any small
> difference would be so tiny it would probably be invisible, assuming
> it could even be measured reliably. If that's true then your small
> difference simply does not matter.
My original message drew to much attention to query rewriting as why I
want delegation. I explained in the same message how I want to use
in-bailiwich delegation - and that's where the big difference is.
> Now I did ask you if you had any numbers or analysis to support your
> claim. Where are they? If you can provide this, I'll be happy to look
> at your methodology and results. And if they show you're correct and
> I'm not, I'll say so in public. Fair enough?
You think I'm comparing CNAME usage to out-of-bailiwick delegations,
which I'm not. No numbers are needed when you're comparing the need to
resolve versus no need to resolve. No need to resolve wins every time.
--
Nate
Failure is not an option.
It comes bundled with your Microsoft product.