Re: Disable Refused answer
On Fri, 4 Dec 2009, Chris Thompson wrote:
[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.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
In article mailman.1194.1259925918.14796.bind-us...@lists.isc.org,
Chris Thompson c...@cam.ac.uk wrote:
On Dec 3 2009, Bill Larson wrote:
[...]
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.]
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.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
On Dec 3 2009, Bill Larson wrote:
[...]
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: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
Search in arm by keyword blackhole will save father of russian democracy :-) 2009/12/3 Dmitry Rybin kirg...@corbina.net Barry Margolin wrote: In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
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 kirg...@corbina.net mailto:kirg...@corbina.net Barry Margolin wrote: In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org mailto:mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@corbina.net mailto:kirg...@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? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
Are you want to disable refused answers for recursion and allow any answers for authoritative information in the same time? 2009/12/3 Dmitry Rybin kirg...@corbina.net 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 kirg...@corbina.net mailto:kirg...@corbina.net Barry Margolin wrote: In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org mailto:mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@corbina.net mailto:kirg...@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? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
Dmitry Rybin wrote: Barry Margolin wrote: In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@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. 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
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
};
_
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
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:
_
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
};
This should work --- one of the scariest phrases in the computing
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
On Dec 3, 2009, at 10:16 AM, Kevin Darcy wrote:
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:
_
view caching-server {
match-recursive-only yes;
blackhole { ! authorized-clients; any; };
// any other resolution configuration goes here
};
This should work --- one of the scariest phrases in the computing field :-)
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...
Chris Buxton
Professional Services
Men Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
In message dcf41a2c-d461-4e78-82cd-0add12051...@menandmice.com, Chris Buxton
writes:
On Dec 3, 2009, at 10:16 AM, Kevin Darcy wrote:
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:
_
view caching-server {
match-recursive-only yes;
blackhole { ! authorized-clients; any; };
// any other resolution configuration goes here
};
This should work --- one of the scariest phrases in the computing field
:-)
True, true. It means, of course, The docs suggest this will work, but I have
n'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 v
iew. Likewise, the description of the blackhole statement makes no mention of
the fact that it's not valid inside a view.
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-users@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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
Chris Buxton cbux...@menandmice.com said: 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disable Refused answer
Hello! I can't find in docs how disable answer (Refused), if recursion for IP is not allowed? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable Refused answer
In article mailman.1159.1259764844.14796.bind-us...@lists.isc.org, Dmitry Rybin kirg...@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? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
