[CentOS] Re: Re: Re: What libs req'd to resolve DNS within achrootjail?

Tue Jan 15 01:32:43 UTC 2008
Mike Kercher <mike at vesol.com>

 

> -----Original Message-----
> From: centos-bounces at centos.org 
> [mailto:centos-bounces at centos.org] On Behalf Of Eric B.
> Sent: Monday, January 14, 2008 5:59 PM
> To: centos at centos.org
> Subject: [CentOS] Re: Re: Re: What libs req'd to resolve DNS 
> within achrootjail?
> 
> 
> "William L. Maltby" <CentOS4Bill at triad.rr.com> wrote in 
> message news:1200354890.5507.35.camel at centos01.homegroannetworking...
> > On Mon, 2008-01-14 at 17:53 -0500, Eric B. wrote:
> >> > Eric B. wrote:
> >> >>>><snip>
> >> >> Thanks for the feedback Rick.  I didn't realize that security 
> >> >> implication.
> >> >> However I'm already running this on a machine that is heavily 
> >> >> firewalled on a VPN so I am fairly sure that no one will be 
> >> >> accessing this externally, but I still would like to restrict 
> >> >> access to particular machines.
> >> >> Ideally,
> >> >> would rather use FQDN to make life easier for me to 
> administer.  I 
> >> >> have created my additional reverse-dns pointer but I am still 
> >> >> having problems with it.
> >> >>
> >> >> nslookup from the server gives me:
> >> >> # nslookup 192.168.3.103
> >> >> Server:         192.168.1.67
> >> >> Address:        192.168.1.67#53
> >> >>
> >> >> 103.3.168.192.in-addr.arpa    name =
> >> >> eric.test.com.3.168.192.in-addr.arpa.
> >> >>
> >> >
> >> > It looks like there is a missing trailing dot in your DNS zone 
> >> > configuration. I doubt you are authoritative for the 
> in-addr.arpa zone.
> >> >
> >> > in your zone file, you should have something like
> >> > 103 IN PTR eric.test.example.
> >> > (notice the last dot). Otherwise, the zone name 
> (@ORIGIN) will be 
> >> > added.
> >> >
> >> >
> >> > make sure you have a matching reverse _and_ forward 
> resolution. you 
> >> > should get something like:
> >> >
> >> > 192.168.3.103 => eric.test.example
> >> > _and_
> >> > eric.test.example => 192.168.3.103
> >> >
> >> > If you only have the reverse lookup, the result is untrusted and 
> >> > sane applications should ignore it.
> >>
> >>
> >> Thanks for the pointer.  Indeed, I was missing the 
> trailing . after 
> >> my FQDN in my revers file.  I have updated my reverse files, and 
> >> nslookup is resolving better, but still not further ahead.
> >>
> >> My reverse file: 3.168.192.in-addr.arpa now contains the 
> following line:
> >> 103             IN PTR  eric.test.com.
> >>
> >>
> >> If I try nslookups now, my results are as follows:
> >>
> >> # nslookup 192.168.3.103
> >> Server:         192.168.1.67
> >> Address:        192.168.1.67#53
> >>
> >> 103.103.168.192.in-addr.arpa    name = eric.test.com.
> >>
> >> # nslookup eric.test.com
> >> Server:         192.168.1.67
> >> Address:        192.168.1.67#53
> >>
> >> Name:   eric.test.com
> >> Address: 192.168.3.103
> >>
> >>
> >> So from that, it seems as though the DNS / rDNS are properly 
> >> configured, does it not?  Similarly, I have both the forward and 
> >> reverse domain name on the DNS server as the nslookups show.  
> >> However, I still get the same error
> >> msg:
> >> Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from
> >> 192.168.103.103
> >              AAA
> > Correct? -----|||
> 
> Whoops - cut & paste typo.  That line is supposed to read:
> Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from 
> 192.168.3.103
> 


Can you post your complete hosts.allow and hosts.deny files?