chrooted - splitdns

[Kevin Darcy]

John Hardy wrote:

>         I have sucessfully installed a chroot-split/dns system.  I have my
> external systems being listed from the Public interface and I have my
> internal systems being listed from the Private interface.  Now the problem
> I'm having is a little complicated.  Basically I don't think my forwarding
> is working.  Let see if I can explain it properly.  One machine, Linux
> 2.2.13, Version "8.2.2-P5", 2 nics, Public and Private interfaces have a
> named process with db files for the external servers on Public and db files
> for the internal servers on Private. The Private interface has a forwarder to
> the public side.

I'm not sure why that's necessary. If configured with the proper hints file,
the private instance should be able to resolve Internet names just fine without
relying on a forwarder.

> Both sides are serving the same domain name.

The same domain *name*? Or the same *domain*? If you mean the latter, then
hopefully the zone served by the external instance is a "shadow" *subset* of
the internal version.

> I am expecting that a private workstation on the private side, should be able
> to request one of our public servers, recieving the answer from the service
> listening on the Public interface.  This is not happening, it times out.

Now you're really confusing me. Why would an internal workstation ever need to
talk to the external instance? Why would you want it to? As I implied above,
the usual "shadow" configuration means that the data in the internal instance
is a superset of the data in the external instance. So the internal machines
talk to the internal instance, and this resolves anything they need. There's no
need for them to talk to the external instance at all. It's best if the only
thing which talks to the external instance is external clients, which should
only be asking about domains delegated to you. If at all possible, you want to
shut recursion off completely on your external instance, or at least restrict
it to address ranges you control or otherwise trust.

> When I startup named, I have 1 error that seems relevant.  But I don't know
> how to fix it.
>
>         Jun 25 16:27:48 ns1 named[7834]: sysquery: sendto([public
> IPxx.xx.xx.xx].53): Operation not permitted

I don't know exactly what "Operation not permitted" signifies on Linux. I think
that's an EPERM error, but on the systems I have ready access to here (Solaris,
AIX), EPERM is not a possible error for the sendto() routine. What does the man
page for sendto() say on your system?

>         Here are my named.conf file "options" for each side
>
>         -Public-
>         options {
>                 directory "/db_ext";
>                 pid-file "/db_ext/pid";
>                 named-xfer "/sbin/named-xfer";
>                 #
>                 #query-source address * port 53;
>                 #
>                 # specify the external IP address of this box
>                 listen-on { PubicIPxx.xx.xx.xx; 127.0.0.1; };
>                 #
>         };

Why is the public instance listening on loopback?

>         When I restart the named servers I get:
>
>         Jun 28 23:37:18 ns named[1116]: reloading nameserver
>         Jun 28 23:37:18 ns named[1116]: Forwarding source address is
> [0.0.0.0].1055
>         Jun 28 23:37:18 ns named[1116]: Ready to answer queries.
>         Jun 28 23:37:18 ns named[1118]: reloading nameserver
>         Jun 28 23:37:18 ns named[1118]: Forwarding source address is
> [0.0.0.0].1056
>         Jun 28 23:37:18 ns named[1118]: Ready to answer queries.
>         Jun 28 23:37:40 ns named[1118]: ns_forw:
> sendto([PublicIPxx.xx.xx.xx].53): Operation not permitted
>
>         I would appreciate some help.  I'm out of options, at least that I
> know of.  I have tried using 0.0.0.0 as a forwarder, I have tried taking
> both sides individually off of listening to 127.0.0.1, and the allow-query.
> I'm hoping someone has an answer.  I am also running IPchains.  However I
> have turned it off to test this and still no luck.  I have ipforwarding on
> in the kernel, I can't see why this is a problem.
>
>         Second issue - what does this mean?
>         Jun 28 23:15:14 ns named[1118]: sysquery: findns error (NXDOMAIN) on
> ns1.{mydomain}.com?

This means that whatever server was asked about the address of
ns1.{mydomain}.com claimed it didn't even exist. This may be a consequence of
your other
(sendto()) problem.
- Kevin