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