<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 7/8/2011 12:11 PM, Joseph S D Yao wrote:
    <blockquote cite="mid:20110708121142.B1111@gwyn.tux.org" type="cite">
      <pre wrap="">
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.

</pre>
    </blockquote>
    Joe,<br>
            Look at how RFC 1034 distinguishes "recursive" from
    "iterative":<br>
    <br>
    <br>
    <blockquote> - 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. <br>
    </blockquote>
    <br>
    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).<br>
    <br>
    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").<br>
    <br>
                                                                       
                                                                       
                                                                       
                                - Kevin<br>
  </body>
</html>