Re: Classless PTR query issue
On Tuesday, May 7, 2013 9:06:53 PM UTC-4, Doug Barton wrote: > On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: > > > On 07.05.13 11:06, Michael Varre wrote: > > >> 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. > > > > > > they use that sucking djbdns-like way of delegating zones. > > > Instead of creating one zone and pointing 16 CNAMEs into it, they want you > > > to create 16 zones. > > > > > > Advise them to read RFC 2317 and do things right way. > > > > https://dougbarton.us/DNS/2317.html I sent them the RFC yesterday and even sent them the KB article from SimpleDNS.com but I think they still have something done incorrectly. It's amazing how large hosts take proper DNS administration for granted these days. I don't have time to teach them how to do this anymore, so unfortunately I think I'm going to throw in the towel and just have them create the PTR records for me...right now I just need them to resolve! Thanks everyone for your input. I will reference this thread for them in the next few weeks if I'm able to fine someone able to make the proper changes. ___ 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
Re: Classless PTR query issue
On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: On 07.05.13 11:06, Michael Varre wrote: 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. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. https://dougbarton.us/DNS/2317.html ___ 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
Re: Classless PTR query issue
On 07.05.13 11:06, Michael Varre wrote: 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. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) ___ 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
Re: Classless PTR query issue
In article ,
Justin T Pryzby wrote:
> It appears they may have manually added NS records for each of 64 IPs.
> That's messy and inelegant for them, and doesn't work right either.
> The ISP is responding with NS for 90.1.1.1, which means that the next
> query must ask a quesion *below* that: something.90.1.1.1. That's why
> a CNAME is needed, with an additional, "artificial" subzone, allowing
> proper delegation. Otherwise, it's a so-called "horizontal" referal.
Actually, this kind of referral works OK -- it's how you find the SOA of
a subdomain, for instance.
The strictly legal way to implement this in the subdomain's server is to
have separate zones for each IP:
zone "65.1.1.1.in-addr.arpa" {
type master;
filename "1.1.1.65.rev";
};
zone "66.1.1.1.in-addr.arpa" {
type master;
filename "1.1.1.66.rev";
};
...
Each of these reverse zone files should then contain a PTR record at the
apex:
@ IN SOA ...
IN NS dns1.yourdomain.com.
IN PTR hostname.yourdomain.com.
In practice, though, what people often do in this case is create a
1.1.1.in-addr.arpa zone. The problem with this is that the responses
will claim authority for the /24, even though the ISP is supposed to be
authoritative. This may cause some servers to reject the responses (or
worse, cache these authority records and lose the ability to do reverse
lookups in the rest of the /24).
But you really should point them to RFC2317, and get them to do it right.
--
Barry Margolin
Arlington, MA
___
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
Re: Classless PTR query issue
and so much for keeping my ip's and hosts private :) ___ 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
Re: Classless PTR query issue
On Tue, May 07, 2013 at 09:52:16AM -0700, Michael Varre wrote: > Thanks Justin, I've been testing with dig and that's how I got the failed > results posted previously. My digs lead me to believe their zones are named > the same as mine, with -'s instead of /'s. > > dig -x 1.1.1.90 +trace > snipped > ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms > > 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. > 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. > ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms > > 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. > ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms > > ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms > > > I've requested they confirm their setup, but I don't know how forthcoming > they'll be. I don't see any "-" (or "/") in your dig output, which indicates that the ISP delegation isn't using RFC2317-style delegation with CNAMES. It appears they may have manually added NS records for each of 64 IPs. That's messy and inelegant for them, and doesn't work right either. The ISP is responding with NS for 90.1.1.1, which means that the next query must ask a quesion *below* that: something.90.1.1.1. That's why a CNAME is needed, with an additional, "artificial" subzone, allowing proper delegation. Otherwise, it's a so-called "horizontal" referal. In the past, when I've requested RFC2317/sub-24 delegation of rev dns, I've included/suggested BIND syntax (but it's still sometimes taken multiple attempts to be correctly implemented). $ORIGIN 196.185.205.in-addr.arpa. 32-47 NS ns.norchemlab.com. 32-47 NS ns1.norchemlab.com. $GENERATE 32-47 $ CNAME $.32-47 Justin ___ 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
Re: Classless PTR query issue
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 NSns.norchemlab.com.
>
> 160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.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 ,
>
> > >
>
> > > Michael Varre 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 j
Re: Classless PTR query issue
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 NSns.norchemlab.com. > > 160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.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 Thanks Justin, I've been testing with dig and that's how I got the failed results posted previously. My digs lead me to believe their zones are named the same as mine, with -'s instead of /'s. dig -x 1.1.1.90 +trace snipped ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms I've requested they confirm their setup, but I don't know how forthcoming they'll be. ___ 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
Re: Classless PTR query issue
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 NSns.norchemlab.com.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.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 ,
> >
> > Michael Varre 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
Re: Classless PTR query issue
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
> In article ,
>
> Michael Varre 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
Re: Classless PTR query issue
In article ,
Michael Varre 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
___
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
Classless PTR query issue
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.
___
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
