Round robin on CNAME

Nate Campi nate at campin.net
Mon Apr 1 19:53:47 UTC 2002


On Mon, Apr 01, 2002 at 08:44:22PM +0100, Jim Reid wrote:
> >>>>> "Nate" == Nate Campi <nate at 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> 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.

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. 



More information about the bind-users mailing list