On 7/8/2011 12:11 PM, Joseph S D Yao wrote:
It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere. IMHBUCO.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone "tld.example" {
type master;
file "data/zone.tld.example";
};
};
zone.tld.example:
$TTL 3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
target CNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record. Of course, I
says to myself, it is trying to do recursion, which is not allowed. I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation. I added to the view:
zone "sub.tld.example" {
type "forward";
forward only;
forwarders { ns1.sub's IP; ns2.sub's IP; };
};
Still not working. Unless I allow recursion! Which is SUPPOSED to be
an entirely etc.
Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?
Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*) I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
Joe,
Look at how RFC 1034 distinguishes "recursive" from "iterative":
- In any system that has a distributed database, a particular name
server may be presented with a query that can only be answered by
some other server. The two general approaches to dealing with this
problem are "recursive", in which the first server pursues the query
for the client at another server, and "iterative", in which the
server refers the client to another server and lets the client
pursue the query.
I think it's pretty clear that what BIND calls "forwarding" is just a
subset of what the standards consider "recursive" resolution, and the
distinction you're trying to make between "forwarding" and "recursion"
isn't sanctioned by the standards. Moreover, in terms of bits and bytes,
a forwarded query *is* recursive (it has the RD set).
Maybe you need to ask yourself why you want to run a "non-authoritative"
nameserver in the first place (?) Are you following best practices for
purposes of security? Well, if you selectively poke "forwarding" holes
in that non-authoritative "wall", then you're deviating from the best
practices and compromising your security. Think about it: when you
forward, you're trusting your forwarders (usually either by IP address
or TSIG key), validating their responses (hopefully there's enough
randomness to prevent a Kaminsky-style attack), populating a cache, etc.
All the things that have led to security issues in the past. It's
exactly those things which led to the "authoritative-only" best practice
in the first place -- it simplifies the interaction, reduces the number
of "moving parts", and thus prevents all sorts of issues. I don't think
you want to be in the position of creating a *false*, Potemkin-Village
sense of security by claiming outwardly to be "authoritative-only", yet
all the while engaging in questionable forwarding practices behind the
proverbial facade. Authoritative-only means authoritative-only: no
recursive resolution allowed, not even on the back-end and/or going by a
different name ("forwarding").
- Kevin
_______________________________________________
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
