A smarter stub resolver??

[Todd Snyder]

>If you're on a closed network and not using forwarders, then you'll
also 
>need a hints file and associated hints-file definition in named.conf,
of 
>course, but even so, we're still not talking about adding a great deal 
>of additional care and feeding...

It's not much, I'll gladly concede, but the simple act of adding a large
number of nameservers, even simple caching ones, introduces more
complexity, more pieces in the puzzle.  They may hum along nicely, until
a day when you have DNS problems and negatively cache something
important and suddenly you're rushing to flush hundreds/thousands of
caches while you're under incident, all so the local system can handle a
failed resolver in a better way.

I don't disagree that this isn't a good solution, and I have used it
myself many times, but to me, it doesn't scale to a DC/DCs full of
servers well.  I'd rather see a more clever resolver that realizes there
is a fault and removes that nameserver from it's pool for
$BACKOFFSECONDS then tries again with an increasing backoff, or
background checks while using the other configured namesevers until it's
back up.  Again, it adds complexity, but it doesn't necessarily add an
attack vector, nor a sysadmin task.  I am sure there are drawbacks to
idea, but there are benefits.  If only I were a programmer ...

Cheers,

Todd.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.