Re: FATAL: Too many queued dnsserver requests

Patrick McManus writes:
> the premise of the question was a single saturated link feeding the
> squid cache and the dns requests/replies being dropped due to queue
> overruns (or RED or whatever.. congestion drops). [...]
> the suggestion I was responding to indicated that a
> solution to this problem was essentially reducing the timeout and just
> asking the DNS question more often, which doesn't make any sense at
> all..

  Well, as a general solution to congestion problems, you're absolutely
right. In my defense, I pointed out that the correct solution is to
add more bandwidth, and also that they should have a local caching
nameserver whether or not they add bandwidth. The issue is what's the
best workaround for them if they can't afford to add bandwidth.

  (I'm sympathetic to this situation, because the company I used to
work for had a single 56kb/s Internet link through '96, for an internal
network with about 1000 users on it. They could have afforded lots
more, but the MIS budgeters could not be convinced that the staff
actually used the Internet to do their work.)

> you've got a single overburdened link and that suggestion just
> adds more work to it.. what you need to do is either put the DNS under
> congestion control too

  If you want to run DNS over TCP, then you've got to have access to
the other end of the link so you can put a server there which can deal
with DNS over TCP. (That will usually translate to extra money paid to
their service provider.) If you don't have that access, you have to
stick with DNS over UDP.

> or move DNS onto some kind of reserved or
> diffserved network so that doesn't happen to it..

  Diffserved networks or extra network connections also tend to cost
extra money. If they have a router on both ends with the CPU to do
some type of QoS, and let them prioritize DNS queries and responses
(but not other UDP traffic) then that would help considerably. A
dedicated traffic-shaping device would be better still. However, if
they don't have one, it may not be in their budget to add it.

> so it's not related to parts of the DNS tree being congested, its
> really a local issue.

  I understood what you were saying, but still feel my comment was a
usable kludge for their situation.

  My assumption was that their WAN link is already at the stage of
partial congestion collapse, and the DNS is losing out first. DNS is
typically low-volume - ca. 2% of average Internet traffic? - so forcing
some retransmits sooner from one server is not likely to send their
network into a complete congestive failure, especially as sooner or
later the query will need to be tried again. Lowered timeouts is not
as good as the adaptive timeouts of TCP, but they're better than simply
having a long timeout on all name queries when the outgoing or incoming
packet is lost.

  -- Clifton

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
        "An absolute monarch would be absolutely wise and good.  
           But no man is strong enough to have no interest.  
             Therefore the best king would be Pure Chance.  
              It is Pure Chance that rules the Universe; 
          therefore, and only therefore, life is good." - AC