Round robin on CNAME

Jim Reid jim at rfc1035.com
Mon Apr 1 08:59:47 UTC 2002


>>>>> "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. 

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.


More information about the bind-users mailing list