Some domains don't resolve.

Kevin Darcy kcd at
Fri Jun 6 04:08:16 UTC 2008

Barry Margolin wrote:
> In article <g29bu2$93j$1 at>, Danny Mayer <mayer at> 
> wrote:
>> 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
>>> them....
>>> </youknowwhat>
>> 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.

                  - Kevin

More information about the bind-users mailing list