logo       

Re: named + dial in in private network: msg#00592

network.dns.bind.user

Subject: Re: named + dial in in private network

If my "thrashing" theory is correct, then the real solution here is to switch
back and forth between a "self-contained" DNS (with your own internal root
zone) and an "inter-dependent" DNS (which looks to the Internet root zone),
depending on whether you're connected to the Internet or not. For the
"inter-dependent" DNS, using a hints file is probably preferable overall to
forwarding, but it's possible that your ISP restricts DNS packets, in which case
forwarding would be your only option.

Why don't you try a test of manually switching between those 2
DNS configurations (private-root and ISP-forwarding) within a few seconds of
connecting/disconnecting, and see if that fixes your problem. If it does, then
you can get a little fancier and see if a root hints config works as well as a
forwarding config for the "inter-dependent" part.


- Kevin

Martin Daser wrote:

> Hello Kevin!
> On the weekend I finally had the time to try what you suggested: I used
> the root server hints instead of the forwarder to my ISP's DNS servers
> in named.conf; I even got a plain new root.hints file ...
>
> It did not work. Not even for the gateway machine.
> So I switched back to my ISP's DNS servers and forward the requests to them.
>
> I am completely clueless ...
>
> >>Kevin Darcy wrote:
> >>Hi Kevin,
> >>thanks so far for you answer.
> >>On my lInux box (gateway) I am using the following resolv.conf file
> >>
> >>nameserver 127.0.0.1
> >>nameserver <dns-of-isp-1>
> >>nameserver <dns-of-isp-1>
> >>
> >>on all the other machines I am refering to the linux box (gateway + dns
> >>server)
> >>
> >>I will certainly try to use a root hint file instead of forwarder
> >>entries. It also has the benefit that I don't have to change the
> >>forwarders if the isp changes its name servers.
> >>
> >>By thrashing you mean a huge increase in dns queries towards the isp's
> >>name servers, right?
> >>
> >>-- martin
> >>
> >>
> >>>
> >>>Well one thing you didn't mention is whether the Linux box is pointed to
> >>>*itself*, i.e. the local "named" instance, for resolving names. If the Li=
> >>>nux
> >>>box is pointed (via /etc/resolv.conf) to your ISP's nameservers for
> >>>resolution, and that works, and all of your other local clients are point=
> >>>ed
> >>>to the Linux box for resolution, and they don't work until you restart
> >>>"named", then this whole set of symptoms boils down simply to:
> >>>
> >>> named requires a restart after I connect to the Internet before it'll
> >>>resolve any names
> >>>
> >>>In that case, my theory would be that during the period that your box is =
> >>>not
> >>>connected to the Internet, "named" is trying to resolve Internet names, a=
> >>>nd
> >>>is unable to because of its inability to talk to Internet nameservers. Al=
> >>>l of
> >>>these outstanding requests stack up, "named" starts "thrashing", and this
> >>>thrashing continues even after Internet connectivity is established.
> >>>Restarting the nameserver puts an end to the thrashing, so that "named" c=
> >>>an
> >>>function normally.
> >>>
> >>>Given your circumstances, you might be better off using a root hints file
> >>>instead of defining the root zone as "type forward" -- I think the
> >>>timeout/retry behavior for forwarders is probably a major contributor to =
> >>>your
> >>>problem here. Failing that, though, I'm not sure that there is a good
> >>>solution for this that does not require triggered restarts of the nameser=
> >>>ver.
> >>>You could probably make the connected/disconnected transitions a little
> >>>smoother by having a special internal-root configuration that you'd run o=
> >>>nly
> >>>when disconnected from the Internet, but then you'd still have to restart=
> >>> the
> >>>nameserver every time you connect or disconnect from the Internet...
> >>>
> >>
> >
> >





<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise