Bypassing DNS?

[Ben Scott]

On 2/23/06, Paul Lussier <p.lussier at comcast.net> wrote:
> Is there a way to tell the resolver libs that if you can't connect to
> the DNS service, to just abort and return? Setting /etc/nsswitch.conf to
>
>   hosts: dns [unavail=continue|return] files
>
> still seems to result in a slight hang while the lookup occurs...

  The real issue here is: How does the stub resolver library know it
can't connect to the DNS service?

  If the full-service resolver (the nameserver configured in
/etc/resolv.conf) is unresponsive for some reason, the resolver has no
way of knowing that.  Remember, UDP is stateless, so all the stub can
do is send a query and wait for a reply.  If the query packet goes
into a black hole, the stub will never know that.

  You can set a timeout in the resolver that says, in effect, "If you
don't hear back within X seconds, give up".  Bruce posted the config
option for that, but that small timeout may cause false timeout errors
when things really are working.  DNS can take a couple seconds even
when everything is working right, and unusual conditions can make
things worse.

On 2/23/06, Paul Lussier <p.lussier at comcast.net> wrote:
>>  If you want more immediate response, I would suggest running a
>> local instance of BIND as a caching server.
>
> Probably not.  This is for an embedded system, for which the desire is
> a little complexity as possible.  Configuring a caching name server
> would a significant layer of complexity for which our support people
> are not qualified to deal with.

  You really think so?  A caching-only nameserver requires no
configuration with BIND, about all you have to do is install it.  You
might want to pre-configure a restriction that it only listens to the
localhost, but that config file would be the same everywhere.  Even if
you wanted to configure forwarders, you could do that with a simple
included file.  What's the big deal?

  If you're worried about footprint, DJB's "tinydns" caching-only
resolver is, well, pretty tiny.

-- Ben