one-zone-only forwarding DNS

[Kevin Darcy]

9.5.5 is old -- upgrade.

But, to the architecture issue... sounds like you need an "internal root
with forwarding exceptions" setup.

   - As per best practices, consider separating the recursive-resolver and
   hosting functions into separate views, separate named instances (listening
   on different IPs) or even separate server instances.
   - If you opt *not* to make such a separation, then at the very least,
   you'll need to replace "recursion no" with "allow-recursion", permitting
   localhost and internal clients. In the absence of recursion being allowed,
   none of your "type forward" zone definitions are going to work.
   - Define an internal root zone that contains delegations for the parts
   of the namespace that you want to resolve for your internal clients, either
   from authoritative data or via forwarding. Being delegated allows
   non-authoritative parts of the namespace to resolve sanely, via "type
   forward" (aka selective or conditional forwarding) definitions in
   named.conf. Queries for anything that doesn't fall under a delegation gets
   NXDOMAIN from your internal root zone, which I believe meets your
   requirements. Note that selective/conditional forwarding is for a whole
   branch of the namespace -- if you want to carve out some parts of a
   namespace that are forwarded, and others that aren't, or if the delegation
   hierarchy seen through forwarding differs from the structure you want
   internally, then it gets complicated, but I won't belabor the point here,
   since I don't know if you have such a requirement or not. Note also that
   when running an internal root, you'll need to make arrangements for reverse
   resolution (the in-addr.arpa and ip6.arpa namespaces).

In skeletal form, a view-based separation would look something like:

view internal
            match-clients xxx # could also use match-destinations, if
listening on multiple IPs
            recursion yes # the default
            zone "." # with delegations
            internal zone #1
            internal zone #2
            etc.
            forwarded zone #1
            forwarded zone #2
            etc.
view hosting
            match-clients all # if not matched above
            recursion no
            hosted zone #1
            hosted zone #2
             etc.

If you separate by named instance and/or server instance, then each of
those views would just become the default view for each instance (with no
"match" clause obviously), and you would protect the "internal" listen-on
address from external queries via your normal access-control methods
(routing, firewalls, etc.)


                                      - Kevin

P.S. I assume that "corp.intranet.de" in your example config is one of the
domains you described as intended to be resolvable from the Internet, but
you don't show a zone-level "allow-query", so, as it stands, it wouldn't be
resolvable outside of your internal network. I'm guessing this was just an
oversight when you composed your example config...

On Tue, Nov 13, 2018 at 6:01 AM Sig Pam <spam at itserv.de> wrote:

> Hi all!
>
>
>
> I’m really despairing on a configuration, and start to wonder if it is
> possible at all.
>
>
>
> Running Bind 9.5.5, I want to serve IP-Addresses for my internal network
> only, and none from the internet, except for a few domains. The idea is I
> don’t want any intranet client to be able to resolve Internet addresses,
> except for a few domains like Microsoft.com and others.
>
>
>
> My named.config looks like this (shortened, copied together from multiple
> files including others):
>
>
>
> acl intranet_nets {
>
>      192.168.94.0/24;
>
>      192.168.1.0/24;
>
>      192.168.5.0/24;
>
>      };
>
>
>
> options {
>
>      directory "/var/cache/bind";
>
>
>
>      allow-query { localhost; intranet_nets;};
>
>      allow-query-cache { localhost; intranet_nets;};
>
>
>
> recursion no;   # switching this on would resolve ANY Internet address,
> which I don’t want
>
>
>
>      dnssec-validation auto;
>
>
>
>      auth-nxdomain no;    # conform to RFC1035
>
>      listen-on-v6 { any; };
>
>
>
> };
>
>
>
> zone "corp.intranet.de" {
>
>      type master;
>
>      file "/etc/bind/db.corp.intranet.de";
>
>      allow-transfer { 192.168.94.242; };
>
>      allow-update { none;};
>
>      };
>
>
>
> zone "94.168.192.in-addr.arpa" {
>
>      type master;
>
>      file "/etc/bind/db.94.168.192";
>
>      allow-transfer { 192.168.94.242; };
>
>      allow-update { none;};
>
>      };
>
>
>
> zone "microsoft.com" IN {
>
> type forward;
>
> forwarders { 9.9.9.9; 194.150.168.168;  8.8.8.8;  8.8.4.4; };
>
> };
>
>
>
>
>
> Running this configuration, my local addresses are correctly resolved,
> external addresses not (good), but DNS-requests for the domain
> Microsoft.com neither (bad!).
>
>
>
> I actually wonder if “forward” is the right keyword (is forward = answer
> to the client: “don’t ask me, ask one of the forwarders” ???), or if I’m
> totally on the wrong way.
>
>
>
> Any support on how to implement this setup is highly appreciated,
>
>
>
>    Sig
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181113/2cd46f40/attachment-0001.html>