Some domains don't resolve.
kcd at chrysler.com
Fri Jun 6 04:08:16 UTC 2008
Barry Margolin wrote:
> In article <g29bu2$93j$1 at sf1.isc.org>, Danny Mayer <mayer at ntp.isc.org>
>> Matus UHLAR - fantomas wrote:
>>> On 01.06.08 17:47, Danny Mayer wrote:
>>>> Don't use forwarders at all. They are not necessary and makes you
>>>> dependent on someone else's DNS. It's rarely necessary anyway and
>>>> provides you with no real benefits. It's surprising the number of people
>>>> who think that this is of benefit to them.
>>> the forwarder of an ISP can have a huge cache which can speed up resolving
>>> of frewquently used names. It also can have configured local reverse and
>>> direct domains that speeds up their resolution.
>>> It can also have local RFC 1918 and RFC 3333 (and possibly other) reverse
>>> zones that may speed up
>>> resolution of those, since there still are many of DNS servers that do not
>>> have them configured.
>>> It's surprising the numbers of people who think that this is not benefit to
>> The surprise is the number of people who believe what has now become
>> something of an urban legend. This is NOT true. If it's so frequently
>> used you would have it in your own cache. If it's not in cache it takes
>> less time to fetch it directly than asking your ISP and finding that
>> it's not there either and having it fetch it and return it to you. I'm
>> not sure where you think that reverse or other domains come into it,
>> it's all the same.
> I disagree. The more users a caching server has, the more likely any
> particular record is going to be in its cache.
> Suppose a particular domain is accessed by 1% of Internet users. If you
> have 100 users, the domain will be cached only if that 1 user has
> accessed it recently. Every time the TTL runs out, that user will have
> to wait for it to be refetched from the source, which might require
> several DNS queries (maybe the NS records or the associated glue records
> are no longer cached).
> But if your ISP has 100,000 users of the same caching server, it will be
> cached if any of 1,000 users have accessed it recently. For any one of
> them, there's only a 0.1% chance that their lookup will be the one that
> has to wait for fetching from the source.
And if you have 100,000 users using the same caching server, it's likely
to experience big spikes of activity (e.g. several thousands of queries,
within the course of less than a second), during which time some users
will experience some extra delay in getting their queries resolved.
The point is, there are so many variables that it's difficult if not
impossible to model this in a vacuum. Try it both ways -- forwarding
versus iterative resolution -- and see which one gives the best
performance. That's the best advice that can be given here, I think.
More information about the bind-users