Why forwarding is a Bad Thing

Jim Reid jim at rfc1035.com
Sun Mar 25 11:45:30 UTC 2001


>>>>> "Simon" == Simon Waters <Simon at wretched.demon.co.uk> writes:

    >> They are not "Nominum preferred", they *are* the root
    >> servers. I suppose Nominum prefers them, just like everyone
    >> else does. Well apart from the crazies who set up their own
    >> rival Internet roots.

    Simon> I was refering to companies using their own root servers
    Simon> internally - not the crazies who think they can usurp ICANN
    Simon> and still not break the Internet.

Fine. But people who set up internal roots should be smart enough to
provide a local root hints file.

    Simon> Okay we all got tired of questions on root hints - but at
    Simon> least they had to read some documentation.

This misses the bigger picture: like running the lightweight resolver
daemon on each host so that IPv6 lookups can complete quickly. lwresd
will "just work" if it's started with no config files because it can
use the compiled-in list of root servers. Assuming the host is on the
internet of course.

    Simon> We are talking about several minutes extra doing DNS lookup
    Simon> for mailing lists of a few hundreds of entries, this is a
    Simon> substantial proportion of the time taken to deliver to such
    Simon> a mailing list.

This may be true in some circumstances, but it's not the whole truth
or nothing but the truth. When forwarding is used, it's possible
there could be a speed up when the first message is sent to the
list. [The extent of that depends on what's in the caches of the
respective name servers, how long the lookups take, network bandwith,
etc, etc.] However after that, the local name server should have
cached all the A, MX and NS records for the list recipients. It would
have done that too if the name server had looked up the names for
itself. After that, further mailings should not see any improved
throughput because of "faster" DNS lookups from any forwarding:
everything's now in the local server's cache. So, all things being
equal, overall DNS lookup times will have no significant difference on
the delivery of subsequent messages to the list (assuming there were
any significant differences for the initial lookups, which I doubt,
but won't quibble about). If you factor in the overhead of
replenishing expired RRs -- with or without forwarding -- they're
likely to be lost in the noise. I doubt if anyone could measure the
difference in this scenario between a forwarding and non-forwarding
server. The chances are that the names will have expired from the name
server that's the forwarding target at the same time they expired from
the local server. Therefore the lookup overhead will be the same apart
from the extra delay of the local server waiting for the target server
to answer a lookup that the forwarding server could have done for
itself if it didn't forward.

IIUC, the biggest latency problem for mailing lists is not DNS
lookups. It's the tardiness of the remote mail servers. The main
performance factor is having smart mail software which can parallelise
delivery: ie the same message can be sent simultaneously to several
recipients. There is a very interesting paper on tuning sendmail for
large mailing lists by Rob Kolstad. It barely mentions DNS and none of
his tuning tricks relied on anything the name servers did. The URL is:
	http://www.usenix.org/publications/library/proceedings/lisa97/full_papers/21.kolstad

I'd be delighted if you or anyone else could point me at another
serious analysis of mailing list throughput and how a forwarding name
server "improved" performance.

    >> >> target server has to be configured with the details of every
    >> >> apex zone in the internal name space. This can be very messy
    >> >> to set up and maintain. And it probably won't be
    >> >> documented....
    >> 
    Simon> Your losing me here. As opposed to what? Configuring every
    Simon> zone to be zone transfered?
    >>  No, letting the name servers find out things for themselves.

    Simon> Your still losing me - what configuration are you thinking
    Simon> off.

Configuring the target of forwarding servers to know about the apex
zones of every internal domain. ie So they resolve those domains
internally instead of looking them up externally.


More information about the bind-users mailing list