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
  • 315

1 Answers1

3

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
  • 31