Disable Refused answer
Dmitry Rybin
I can't find in docs how disable answer (Refused), if recursion for IP
is not allowed?
Barry Margolin
Dmitry Rybin <kir...@corbina.net> wrote:
What do you expect it to do instead? Not respond at all?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Dmitry Rybin
> In article <mailman.1159.1259764...@lists.isc.org>,
> Dmitry Rybin <kir...@corbina.net> wrote:
>
>
Drop not allowed request.
Peter Andreev
In article <mailman.1159.1259764...@lists.isc.org>,
Dmitry Rybin <kir...@corbina.net> wrote:
Hello!
I can't find in docs how disable answer (Refused), if recursion for IP is not allowed?
What do you expect it to do instead? Not respond at all?
Drop not allowed request.
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Dmitry Rybin
This is not answer. I wont to disable Refused answers for not allowed
client in recursion.
Peter Andreev wrote:
> Search in arm by keyword "blackhole" will save father of russian
> democracy :-)
>
> 2009/12/3 Dmitry Rybin <kir...@corbina.net <mailto:kir...@corbina.net>>
>
> Barry Margolin wrote:
>
> In article
> <mailman.1159.1259764...@lists.isc.org
> <mailto:mailman.1159.1259764...@lists.isc.org>>,
> Dmitry Rybin <kir...@corbina.net <mailto:kir...@corbina.net>>
Peter Andreev
Give me parabellum :)
This is not answer. I wont to disable Refused answers for not allowed client in recursion.
Peter Andreev wrote:
Search in arm by keyword "blackhole" will save father of russian democracy :-)2009/12/3 Dmitry Rybin <kir...@corbina.net <mailto:kir...@corbina.net>> <mailto:mailman.1159.1259764...@lists.isc.org>>,
Dmitry Rybin <kir...@corbina.net <mailto:kir...@corbina.net>>
wrote:
Hello!
I can't find in docs how disable answer (Refused), if
recursion for IP is not allowed?
Kevin Darcy
> Barry Margolin wrote:
>>
>
This is not compatible with the DNS protocol, as defined:
RFC 1034, Section 4.3.1:
---
If recursive service is requested and available, the recursive response
to a query will be one of the following:
- The answer to the query, possibly preface by one or more CNAME
RRs that specify aliases encountered on the way to an answer.
- A name error indicating that the name does not exist. This
may include CNAME RRs that indicate that the original query
name was an alias for a name which does not exist.
- A temporary error indication.
If recursive service is not requested or is not available, the non-
recursive response will be one of the following:
- An authoritative name error indicating that the name does not
exist.
- A temporary error indication.
- Some combination of:
RRs that answer the question, together with an indication
whether the data comes from a zone or is cached.
A referral to name servers which have zones which are closer
ancestors to the name than the server sending the reply.
- RRs that the name server thinks will prove useful to the
requester.
---
Note that "no response" is not one of the options.
You should probably implement this outside of DNS and BIND, e.g. a stateful firewall which would, by policy, drop incoming DNS query packets from certain source-address ranges, which have the RD bit set in the DNS query packet header.
- Kevin
Chris Buxton
> Hello!
>
> I can't find in docs how disable answer (Refused), if recursion for IP is not allowed?
Something like this should work:
_________________________________
options {
directory "/var/named";
};
acl authorized-clients {
192.0.2.1;
};
view caching-server {
match-recursive-only yes;
blackhole { ! authorized-clients; any; };
// any other resolution configuration goes here
};
view auth-server {
// zones go here
};
_________________________________
Note that there is no need to use the allow-query-cache, allow-query, allow-recursion, or recursion statements in either view. All recursive queries will be caught by the first view, which will drop queries by unauthorized clients - no refusal will be sent.
If an authorized client sends a recursive query to the server for local authoritative data, as long as the NS records are configured correctly (possibly along with stub zone statements in the caching-server view), the server will query itself (iteratively, so hitting the auth-server view) and find the data.
The only way in which this differs from what you want is, if someone sends a recursive query for your authoritative zone data from an unauthorized IP, the query will be dropped. But this will probably only happen in testing with dig or nslookup, and it can be worked around (by the user) by turning off the RD flag in the request.
Chris Buxton
Professional Services
Men & Mice
Kevin Darcy
> On Dec 2, 2009, at 6:40 AM, Dmitry Rybin wrote:
>
>
>> Hello!
>>
>> I can't find in docs how disable answer (Refused), if recursion for IP is not allowed?
>>
>
> Something like this should work:
> _________________________________
>
> options {
> directory "/var/named";
> };
>
> acl authorized-clients {
> 192.0.2.1;
> };
>
> view caching-server {
> match-recursive-only yes;
> blackhole { ! authorized-clients; any; };
> // any other resolution configuration goes here
> };
>
> view auth-server {
> // zones go here
> };
>
field :-)
Unfortunately, "blackhole" can only appear the (global) "options" clause:
% cat /tmp/buxton.example
options {
directory "/tmp";
};
acl authorized-clients {
192.0.2.1;
};
view caching-server {
match-recursive-only yes;
// any other resolution configuration goes here
blackhole { ! authorized-clients; any; };
};
% ./named-checkconf /tmp/buxton.example
/tmp/buxton.example:12: unknown option 'blackhole'
% ed /tmp/buxton.example
218
12m2
1,$p
options {
directory "/tmp";
blackhole { ! authorized-clients; any; };
};
acl authorized-clients {
192.0.2.1;
};
view caching-server {
match-recursive-only yes;
// any other resolution configuration goes here
};
w
218
q
% ./named-checkconf /tmp/buxton.example
%
- Kevin
Chris Buxton
> Chris Buxton wrote:
>> On Dec 2, 2009, at 6:40 AM, Dmitry Rybin wrote:
>>> Hello!
>>>
>>> I can't find in docs how disable answer (Refused), if recursion for IP is not allowed?
>>
>>
>> Something like this should work:
>> _________________________________
>>
>> match-recursive-only yes;
>> blackhole { ! authorized-clients; any; };
>> // any other resolution configuration goes here
>> };
>>
>
True, true. It means, of course, "The docs suggest this will work, but I haven't actually tested it."
> Unfortunately, "blackhole" can only appear the (global) "options" clause:
I'm happy to be corrected. You'd never know this from reading the BIND ARM.
From the description of the view statement:
Many of the options given in the options statement can also be used
within a view statement, and then apply only when resolving queries
with that view.
There is no definitive list of the options that can or can not be used in a view. Likewise, the description of the blackhole statement makes no mention of the fact that it's not valid inside a view.
So, to the original poster, we're back to "it can't be done with BIND configuration." Of course, you could hack the BIND source code...
Mark Andrews
In message <DCF41A2C-D461-4E78...@menandmice.com>, Chris Buxton
writes:
doc/misc/options gives a definitive list. It is built from the parser.
> So, to the original poster, we're back to "it can't be done with BIND configu
> ration." Of course, you could hack the BIND source code...
>
> Chris Buxton
> Professional Services
> Men & Mice
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Bill Larson
> There is no definitive list of the options that can or can not be used in
a view. Likewise, the description of the blackhole statement makes no
mention of the fact that it's not valid inside a view.
There is the "doc/misc/options" file in the BIND sources that lists the many
possible items that can be inside a "view", along with
the "options", "server", "zone", etc.
There is the "doc/misc/options" file in the BIND sources that lists the many
possible configuration items available and what section of the configuration
that can be used. The "view" section can include many different items,
but "blackhole" isn't one of them.
This also identifies "blackhole" as only being part of the "options"
clause. Also, the ARM mentions "blackhole" as part of the "options" section
and not in the "view" section.
> So, to the original poster, we're back to "it can't be done with BIND
configuration." Of course, you could hack the BIND source code...
Yes, we are back to that. Another "can't get there from here".
Then again, I've never been sure what the original requester was asking
for. If he didn't want to give an answer out to someone on a particular
network, then the "blackhole" option would seem to be a perfect solution in
the first place.
Thanks for your help on this list,
Bill Larson
Chris Thompson
[...]
>Then again, I've never been sure what the original requester was asking
>for. If he didn't want to give an answer out to someone on a particular
>network, then the "blackhole" option would seem to be a perfect solution in
>the first place.
| blackhole
|
| Specifies a list of addresses that the server will not accept
| queries from or use to resolve a query. [...]
^^^^^^^^^^^^^^^^^^^^^^^^^
So it's not suitable for blocking out large chunks of the external world
which may contain nameservers you need to to do recursive lookups.
[It's never been entirely clear to me why these functions have to be
combined, especially given that "server [ipaddr/len] {bogus yes;};"
can be used to block outgoing queries.]
--
Chris Thompson
Email: ce...@cam.ac.uk
Barry Margolin
Chris Thompson <ce...@cam.ac.uk> wrote:
I think it's for backwards compatibility with the old BIND 4.x blackhole
option. I don't think 4.x had anything analogous to the bogus server
option, all you could do was blackhole individual IPs in both directions.
Tony Finch
>
> [It's never been entirely clear to me why these functions have to be
> combined, especially given that "server [ipaddr/len] {bogus yes;};"
> can be used to block outgoing queries.]
The CIDR syntax for server clauses is relatively new. Before it was added
the only option for blocking large chunks of address space was to use the
blackhole feature.
(We used it on our MX's name servers to stop DNS queries triggered by
incoming email from probing our internal private address space.)
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.