Classless PTR query issue

Tue May 7 18:06:03 UTC 2013

On Tuesday, May 7, 2013 12:04:10 PM UTC-4, Justin T Pryzby wrote:
> I recommend "dig +trace -x" on one of your assigned IPs.  Compare with
> 
> the result from a known-good sub-24 rev dns delegation.  The ISP
> 
> should be returning something like:
> 
> 
> 
> 162.48.168.205.in-addr.arpa. 43200 IN   CNAME   162.160-175.48.168.205.in-addr.arpa.
> 
> 160-175.48.168.205.in-addr.arpa. 43200 IN NS    ns.norchemlab.com.
> 
> 160-175.48.168.205.in-addr.arpa. 43200 IN NS    ns1.norchemlab.com.
> 
> 
> 
> and your NS should respond for the 160-175 zone.  The particular
> 
> naming convention doesn't matter, but has to be consistent between you
> 
> and your ISP.  The filename of the zone doesn't need to match the zone
> 
> name, although that seems to be a popular misconception..  Slashes (as
> 
> in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention
> 
> since, if the filename and zone DO match, they imply use of a
> 
> subdirectory.
> 
> 
> 
> Good luck,
> 
> Justin
> 
> 
> 
> On Tue, May 07, 2013 at 08:45:49AM -0700, Michael Varre wrote:
> 
> > 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.
> 
> > 
> 
> > _______________________________________________
> 
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> > 
> 
> > bind-users mailing list
> 
> > bind-users at lists.isc.org
> 
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> >

So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window:

They use SimpleDNS
Record Name: 65.246.59.108.in-addr.arpa
DNS Server (FQDN): dns1.kishmish.com.
TTL: 1 Hour

I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64.