3

For history reasons we have both internal (192.168.0.0/16) and public IPs on hosts on one domain (example.com). I now want to split this up so that internal hostnames are not resolved for external users.

My current plan is to use bind with RPZ.

my named.conf is as following:

options {
    directory "/var/named";
    pid-file "/run/named/named.pid";

    // Uncomment these to enable IPv6 connections support
    // IPv4 will still work:
    //  listen-on-v6 { any; };
    // Add this for no IPv4:
    //  listen-on { none; };

    allow-recursion { localhost; };
    allow-transfer { none; };
    allow-update { none; };

    version none;
    hostname none;
    server-id none;
    response-policy { zone "rpz"; };
};

zone "localhost" IN {
    type master;
    file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "127.0.0.zone";
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
    type master;
    file "localhost.ip6.zone";
};

zone "255.in-addr.arpa" IN {
    type master;
    file "empty.zone";
};

zone "0.in-addr.arpa" IN {
    type master;
    file "empty.zone";
};

zone "." IN {
    type hint;
    file "root.hint";
};

zone "rpz" {type master; file "rpz"; allow-query {localhost;}; };

my rpz zone file is as following:

$TTL 1H
@                 SOA LOCALHOST. named-mgr.example.com (16 1h 15m 30d 2h)
@ IN    NS  localhost.
support.example.com     A   192.168.1.1
cname.example.com   CNAME support.example.com
*.example.com CNAME rpz-passthru.
*   CNAME .

When I query for support.example.com I get the result I want:

# dig +short support.example.com @127.0.0.1
192.168.1.1

But when I query for cname.example.com the IP is resolved but the client is informed that he is in an RPZ zone.

# dig +short cname.example.com @127.0.0.1
support.example.com.rpz.
192.168.1.1

Alternatively I can change the CNAME in the zone file as following:

cname.example.com   CNAME support.example.com. ;mind the period at the end

But this will prevent bind from recursively resolving the cname:

# dig +short cname.example.com @127.0.0.1
support.example.com.
# dig +short support.example.com. @127.0.0.1
192.168.1.1

Can you explain what I do wrong?

Thanks Clemens

Clemens Bergmann
  • 305
  • 1
  • 3
  • 12
  • You do not need RPZ for what you want, bind views should be enough. – Patrick Mevzek Nov 29 '17 at 18:51
  • I think I did not explain my goal. The domain is hosted by an external provider. My goal is to have the internal hosts resolved by an internal resolver and if that Host is not found internally ask the external DNS server for the information. I also don't want to mirror the external hostnames in the internal domain because that is an administration mess. Could you explain how I can do that with views. Thanks – Clemens Bergmann Nov 30 '17 at 05:13
  • Are you restricted to use other software? `dnsmasq` may be a better fit. – Patrick Mevzek Nov 30 '17 at 15:48
  • no, I am not restricted. I currently run dnsmasq as a test and it works great. The problem is that I use foreman to provision VMs and the foreman-dnsmasq plugin uses host-record configuration entries. We use a lot of CNAMES and dnsmasq does not allow cname entries that point to host-record entries. – Clemens Bergmann Nov 30 '17 at 22:24

1 Answers1

2

Its quite a late reply, but this has been answered on the isc mailing list. Unfortunately you can not chain together multiple rpz-records like

cname.example.com    CNAME  support.example.com.
support.example.com      A   192.168.1.1

rpz is a one shot operation. If your query causes 2 lookups (which happens automatically when CNAME is involved) - only the first lookup one will be handled by rpz.

You need to change your config to

cname.example.com       A   192.168.1.1
support.example.com     A   192.168.1.1

... where each entry can be answered with only one lookup.

When not using a cname record you also do not need to worry about the necessity of the period behind the cname record ;)
Anyways, if you must use CNAME records in rpz file, then please do add the period. Everything else does not make much sense in regards to rpz.

DonEstefan
  • 21
  • 3