chrooted - splitdns

[Kevin Darcy]

John Hardy wrote:

> >
> >
> > 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.
>
> I said successfully, not properly.  :)
> You may have hit the nail on the head.  I did nothing to the hints file.  I
> purchased and read the O'Reily DNS and BIND 3rd edition and found it lacking
> some of what I needed.  But I don't know what needs to be changed within the
> hints file.  Will you tell me what I need, or where to get the information I
> need use?  My hints file only contains the root servers.

Just make sure you have the "official" Internet root hints file. If you get rid
of forwarding, as I'm suggesting, then the contents of the hints file becomes
very important.

> > > 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.
>
> My server is the master for a domain name 'patchlink.com'.  This is the
> domain name I spoke of.  I have internal machines in the patchlink.com
> domain...and I have external servers (like www) in the patchlink.com domain
> space also.  The outside database files for patchlink.com are a simplistic
> version of what I have on the inside (only showing for www and mail, etc).
> Isn't this what I want?  I'm am expecting that I want to have only 1
> database with this record to my www in the outside database.  I can, and I
> am right now, setting up patchlink.com in both my inside and outside, and
> pointing that record's IP address to the outside IP.  Is this correct or
> incorrect?
>
> Inside says: www        IN      A       64.249.24.250
> Outside says www        IN      A       64.249.24.250
>
> I would prefer the inside client to send the request to the inside dns
> server.  It realizes that it does not have the proper information, and
> forwards it to the outside server which knows it is authoritative and
> answers the query.  Is this possible?

Not yet. The "views" mechanism of BIND 9 should implement this.

> Or do I need to make entries in both
> the inside and the outside databases for anything I am hosting on the
> outside?

Currently, that's what you need to do. And once the internal instance has a
superset of the data for the zone(s) in question, there shouldn't be any need
to forward.

Note that what I just said only applies when you want separate inside/outside
views of the zone(s) in question: if you have zones which are the *same*
inside/outside, just define them on the external instance and the internal
instance will still find them through the normal referral mechanism. You could
possibly make this more efficient by making the internal instance a stub or
slave for the zone(s).

> > > 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?
>
> I have it listening so that when I'm on that box locally, I can get
> requests.

Okay, but again, if your internal instance can resolve everything your external
instance can, and more, why not have *it* listen to the loopback interface? You
can always point "dig" or whatever to the external instance if you need to
troubleshoot a problem.


- Kevin