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