On 02/21/2013 01:54 PM, Matus UHLAR - fantomas wrote:
On 21.02.13 12:45, Robert Moskowitz wrote:
Fact:
No clients could access DNS from my server, both internal and
external (I have hotspot on my cellphone, so I can attach a client to
it to get external testing) UNTIL I added the allow-query option.
Once added things started working right.
Which BIND version do you use?
Centos 6.3 which Redhat has bind 9.8.2 with patches they have included;
most notably the security patches.
Do you use your own named.conf? Some OSes/distributions provide multiple
included files with some defaults that may deny access, for example.
Are you sure your named.conf doesn't include such file?
Yes, I have crafted the named.conf and all of its includes. It was at
first a port of what I was running on Centos 5.5 which was bind 9.3.6
(thus before the changes wrought by by 9.4.1.P1). I added a few items
from the default named.conf that came with Centos 6.3, notably the
DNSSEC and support for port randomization (instead of set to 53).
All I can report is what was not working and what made it work.
allow-query SEEMS to be working the same way as allow-query-cache.
but they both do different things.
I get that. But I had neither, thus living with the defaults. Adding
'allow-query { httnet;}' got my local clients working again, and to any
for when I was testing via my cellular connection.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were
getting denied access. It was painful for a little while.
Probably they did not have a recursion enabled. allow-recursion
defaults
to local networks, if not specified directly or by allow-query-cache.
I had the recursion yes option in my internal view. But even queries
of zones it was master for were coming up DENIED without the
allow-query option.
There's something strange about this issue. The default for
allow-query is
"all" and I don't think this was different any time.
Are you sure there's no other "allow-query" directive anywhere in your
named's config files?
No. None. There was a commented one that came with the default, but it
was commented out. It WAS set to localhost, but again it was commented out.
Recursion seems to be working with just "recursion yes" here.
Recursion by itself, yes. But the default for allow-recursion might
not be
enough for you.
In fact, you can use "allow-recursion { all; };" and still only
internal
clients (in internal view) would have it allowed.
So "recursion yes" does not override "allow-recursion"? Strange.
recursion yes/no will tell the server (not) to recurse at all.
allow-recursion only specifies, for whom to recurse.
"recursion no" will disable recursing for all (matching) clients.
"recursion yes" will enable recursing, but only for allowed clients.
So for my external zone with "recursion no", I can leave off the
"allow-recursion".
What does allow-recursion add with given all the other restrictive
clauses?
It allows specified clients to use recursion. Both allow-query-cache
and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.
Then what is the basic recursion option for now? Is it just a
hold-over from more trusting days?
it's kind of general switch to allow/deny recursion.
GOt it. Thanks.
_______________________________________________
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
