Classless PTR query issue
Michael Varre
mvarre at gmail.com
Tue May 7 15:45:49 UTC 2013
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
> In article <mailman.240.1367938655.20661.bind-users at lists.isc.org>,
>
> Michael Varre <mvarre at gmail.com> wrote:
>
>
>
> > I'm setting up a new zone, similar to the many I've created successfully on
>
> > other ISPs to answer with PTR records for a /26 the ISP has sub-delegated to
>
> > my dns servers and it continues to fail:
>
> >
>
> > May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external: query
>
> > (cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
>
> >
>
> > My named.conf is setup as
>
> > zone "64-26.1.1.1.in-addr.arpa" {
>
> > type master;
>
> > file "/var/named/64-26.1.1.1.in-addr.arpa.db";
>
> > };
>
> >
>
> > zone record is:
>
> > $TTL 14400
>
> > 64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
>
> > me.my.com. (
>
> > 2013050702 ;Serial Number
>
> > 86400 ;refresh
>
> > 7200 ;retry
>
> > 1209600 ;expire
>
> > 86400 ;minimum
>
> > )
>
> > 64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
>
> > 64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
>
> > 90 14400 IN PTR apple.somedomain.com.
>
> >
>
> >
>
> > Mind you this is a cpanel server and this is the first time I've tried
>
> > setting up reverse dns to be setup by a cpanel server, but I'm not sure this
>
> > is relevant. It creates two views, internal and external. This is getting
>
> > serviced out of the external view, which really is just setup to answer any
>
> > question for which it has an answer. So i _really_ don't think it's relevant
>
> > but for the sake of troubleshooting I thought I might disclose that.
>
> >
>
> > Anyone have any ideas? Thanks in advance.
>
>
>
> If you're getting queries for 90.1.1.1.in-addr.arpa from outside
>
> clients, it means that the ISP has not set up the proper classless
>
> reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
>
> of 64-26.1.1.1.in-addr.arpa.
>
>
>
> But the client IP appears to be one of your own addresses. They should
>
> be pointing to your caching server, not the authoritative server. It
>
> should then follow the ISP's delegation. If you're using the same
>
> server for auth and caching, you need to put the local IPs in the
>
> allow-query ACL.
>
>
>
> --
>
> Barry Margolin
>
> Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how to delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside would point to it being setup wrong by the ISP? .90 is one of my assigned IP's withing my /26. My GW IP address is .65. Maybe that is where I've gone wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a random number (one of the downfalls of obfuscating IP's on a mailing list). consider that really 9.9.9.9, and that it is NOT one of my IP's - just a client on the internet.
More information about the bind-users
mailing list