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-us...@lists.isc.org>,
> >
> > Michael Varre <mva...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
