I'm running 9.3 on RHEL 5.4.
My options are:
options {
directory "/var/named";
query-source address 10.0.0.3;
allow-query { internaldns; externaldns; dswadnsalias; };
allow-recursion { internaldns; externaldns; };
blackhole { blackhats; };
version none;
};
In each of my zones including arpa zones I have
allow-query { any; };
This works fine for blocking recursion for sites such as google from
outside my network yet still allowing lookups of my zones from outside
and sounds like what the OP says he is intending to do.
The above worked before I upgraded from 5.3 to 5.4 so should work on
CentOS as well since it is a binary compile of RHEL source.
I did run into some oddities in setting up arpa zones to be able to
query them inside my network and outside my network so I have things
like:
# Special notation required for internet delegation (e.g. dig -x ...)
#
zone "192/27.84.44.12.IN-ADDR.ARPA" {
type master;
file "arpa.12.44.84";
allow-query { any; };
};
# Standard notation required for direct lookups (e.g. dig @dswands1 -x
...)
#
zone "84.44.12.IN-ADDR.ARPA" {
type master;
file "arpa.12.44.84";
allow-query { any; };
};
Note this is not the difference in views but difference in how I get to
the server. I later implemented views which probably obviated the
above since I'd only see one or the other depending on where I came
from. However, I note it as originally I was pulling my hair out trying
to figure out why digs directly to my DNS server via the internal facing
interface wouldn't resolve like the ones on the external facing
interface.
-----Original Message-----
From: bind-users-bounces+jlightner=water....@lists.isc.org
[mailto:bind-users-bounces+jlightner=water....@lists.isc.org] On Behalf
Of Matus UHLAR - fantomas
Sent: Tuesday, February 23, 2010 4:19 AM
To: bind-users@lists.isc.org
Subject: Re: Query denied errors on PTR records for delegated zone
On 22.02.10 16:26, Geoff Sweet wrote:
> I have an on-going problem that has totally stumped me. I have a
CentOS
> 5.3 server that I am using the builtin Bind (9.3) to serve our zones.
Our
> ISP has provisioned us a block of IP's and has delegated our name
servers
> as authoritative for the reverse zone info for that block. Name
> resolution for A records works perfect. What has me totally baffled
at
> this point is that I can not get PTR records to work. All queries to
my
> reverse zone are answered with denied errors:
>
> Feb 22 04:10:14 ns1 named[19789]: client 72.247.123.69#52683: query
(cache) '14.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 05:15:26 ns1 named[19789]: client 72.247.123.69#61264: query
(cache) '50.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 10:12:03 ns1 named[19789]: client 72.246.192.167#52219: query
(cache) '39.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 11:05:11 ns1 named[19789]: client 96.17.73.207#61038: query
(cache) '24.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 11:33:23 ns1 named[19789]: client 72.247.123.69#61049: query
(cache) '55.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 13:41:45 ns1 named[19789]: client 96.17.166.181#60054: query
(cache) '31.173.150.66.in-addr.arpa/PTR/IN' denied
> zone "0-59.173.150.66.in-addr.arpa" {
they are not asking for your zone. They are asking for zone
"173.150.66.in-addr.arpa" which I don't see on your nameserver.
All those IPs are from akamai and they should not even go to your
server, if
you are watching at ns1.wemadeusa.com. or ns2.wemadeusa.com.
either akamai has broken dns clients, or someone (you?) has been asking
them
to query your servers directly for reverse zone you don't provide.
> And here is the 0-59.173.150.66.in-addr.arpa.zone file (I have deleted
some of the name information for security):
>
>
> $TTL 3600
> @ IN SOA ns1.wemadeusa.com.
hostmaster.wemadeusa.com. (
> 2010021501 ; serial
> 600 ; refresh
after 10 minutes
> 3600 ; retry after
1 hour
> 604800 ; expire after
1 week
> 86400 ) ; minimum TTL
of 1 day
>
> IN NS ns1.wemadeusa.com
> IN NS ns2.wemadeusa.com
You are missing trailing dots here. Note that without them the current
$ORIGIN is appended, which results in:
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns2.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns1.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
Try fixing this first, maybe this is your real problem.
--
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.
Linux is like a teepee: no Windows, no Gates and an apache inside...
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
