forwarding queries to another server (huh?)

Kevin Darcy kcd at daimlerchrysler.com
Fri Mar 23 03:03:04 UTC 2001


peter at technical-reality.com wrote:

> Look, I'm really messed here.  I've spent 2 entire days trying to get
> this seemingly simple arrangement to work.
>
> I was wondering that maybe something queer happens when the default
> name server (nsfoo) forwards to the forwarder (nstest) through the
> firewall?  Is there a firewall issue when one dns server talks to
> another?

Could be. Have you looked at the firewall logs?

> Does it still use UDP?

Yes.

> Can it be a port issue?

Possibly. The "standard" set of rules for allowing DNS used to be simply "source
and destination ports 53 in both directions". But BIND 8 and later uses a random
unprivileged port for sending queries (like when it is forwarding) and receiving
responses to those queries. So the rules have become more complicated. Now it's
"any unprivileged source port outbound to destination port 53" (for the queries
your server is making) and "source port 53 inbound to any unprivileged destination
port" (for the responses to those queries). If your firewall is "stateful" enough,
it might be able to lock things down further, so that only responses to
recently-made queries would be accepted inbound.

Or, you could configure "query-source" to use port 53, and then the old rules
should work. But that's gross and insecure. Better to fix the firewall rules to
accommodate the way things were *meant* to be.

> I can resolve fine using nsfoo's resources but maybe the extra trips
> are screwing things up.  Also, is it possible that I need to change
> timeout settings?  I (the dns client) am separated from the firewall
> (via T1) by a distance of about 10 km (5.5 miles).

There aren't any timeout settings that are configurable. Do you *notice* delays
when you do queries manually from your box? My experience has been that named waits
a long time before giving up on its one-and-only forwarder, when configured in
"forward only" mode. Certainly long enough to be noticeable to a human.

Offhand, if folks can use forwarding over cross-country or even international
28.8K dialup connections, or through satellites with their horrible latency times,
then it seems like you should be fine on a T1 going only 10km...

If you suspect timeout problems, maybe you should turn on debugging and see if
named is timing out and retrying. But I think firewall problems are more likely
than timing issues. You could try the "query-source" kludge just to test that
theory, and if it pans out, work on the firewall rules. Otherwise, attack things
from the timing angle.

By the way, I notice that the forwarder address you "anonymized" starts with "172".
Is this a private (RFC 1918) address, by any chance? (This is one of the reasons
why it's so frustrating when people "anonymize" their nameserver configurations
when posting them here). You're not trying to route to a private address over the
Internet, are you?


- Kevin

> peter at technical-reality.com wrote:
> >
> >> Hi,
> >>
> >> I have an internal domain, say foo.bar.com.  I have a name server
> >> behaving properly for it.  Call it nsfoo.
> >>
> >> Now I have set up a test environment domain, say test.bar.com.  Note
> >> that it's not a subdomain of the first.
> >>
> >> I want a name server (nstest) on test.bar.com to handle its own
> >> queries.  That is, when nsfoo receives those queries it makes nstest
> >> deal with them.
> >>
> >> In named.conf on nsfoo I have the following entry:
> >>
> >> zone "test.bar.com" {
> >>         type forward;
> >>         forward only;
> >>         forwarders{
> >>                 172.xxx.xxx.xxx;
> >>         };
> >> };
> >>
> >> But alas it doesn't work.
> >
> >It should, assuming you have the necessary network connectivity between
> >nsfoo and nstest, and that nstest allows nsfoo to query it. Be aware,
> >however, that if nsfoo has the answer cached, then it doesn't *need* to
> >forward the query to nstest. So not every query for a "test.bar.com"
> >name will necessarily generate a forwarded query -- only the uncached
> >ones will.
>





More information about the bind-users mailing list