Some domains don't resolve.

[Kevin Darcy]

Matus UHLAR - fantomas wrote:
>> Ezequiel Aguerre wrote:
>>     
>>> Thanks for the advice, but no matter what forwarders I use, it's always
>>> broken. I've tried with mi ISP's forwarders, and other DNS servers (those
>>> from OpenDNS, and others), with no luck at all :(
>>>       
>
> 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. 
This is dependent on a complex and diverse variety of factors. What are 
the relative latencies between your resolver, your ISP's server farm, 
and the Internet backbone? How busy are the ISP's resolvers (both 
sustained and peak)? What server capacity do they have? How often do 
they restart/reboot, thus clearing their caches? What are the query 
patterns of all of the clients of that ISP and what are the relative TTL 
values of the most frequently-queried names and all of the intermediate 
nodes in their respective delegation hierarchies?

What I usually tell folks is "try it and see if there is a 
measurable/noticeable benefit". Most of us don't have complex, 
multi-variable modeling tools available to us to verify "on paper" 
whether forwarding would make sense from a performance standpoint or 
not: we sometimes have to rely on good old trial & error. If you get 
better performance from forwarding, then it might make sense to use that 
resolution mechanism.

But, one thing I'd point out: while forwarding may improve the 
performance of the *best* and perhaps the *average* case, it also 
carries the risk of degrading the performance of the *worst* case, where 
the round-trip time of the ISP cache miss gets *added* to the time it 
takes to go out and fetch the information iteratively. Some environments 
want to minimize their worst-case times, even if means degrading the 
average. This is because some apps have a touchy threshold beyond which 
they will give a fatal error if the name doesn't resolve in a timely 
fashion. Yes, this is a design flaw in these apps, but the reality is 
that sometimes infrastructure needs to accommodate app brokenness.
> It also can have configured local reverse and
> direct domains that speeds up their resolution.
>   
These could be set up as *selectively* forwarded, if desired.
> 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.
>   
Possible solutions: set them up locally, or implement selective forwarding.

- Kevin