bind9 separated zone file for *.sub.domain.com

Question

I want to create sub subdomain that are only visible from my private network.

My named.conf.local looks like this:

acl internals {
    127.0.0.0/8;
    192.168.1.0/24;
};

view "internal" {
    match-clients { internals; };

    zone "local.domain.com" {
      type master;
      file "/var/lib/bind/local.domain.com.hosts";
    };

    zone "1.168.192.in-addr.arpa" {
      type master;
      notify no;
      file "/var/lib/bind/192.hosts";
    };
};

view "external" {
    match-clients { any; };

    zone "domain.com" {
        type master;
        file "/var/lib/bind/domain.com.hosts";
    };
};

How can I create the internal and external zone files, if I dont want to expose the internal ip of the dns server on my external zone declaration?

I dont want to do this, I dont want anyone to see the internal ip:

$ORIGIN local.domain.com.
@                                   IN      NS          ns1.local.domain.com.
ns1.local.domain.com.               IN      A           192.168.1.3

score 1 · Answer 1 · answered Apr 28 '21 at 20:49

Assuming example.com (RFC domain) rather than domain.com which is a valid domain

If you're wanting different views, but mostly the same content you want to put the content in one file, the views in 2 separate. The 2 separate then include the one content (so you don't maintain stuff in different places). Your internal one can have additional content.

Your named.conf.local would then be

acl internals {
    127.0.0.0/8;
    192.168.1.0/24;
};

view "internal" {
    match-clients { internals; };

    zone "example.com" {
        type master;
        file "/var/lib/bind/example.com.internal-hosts";
    };

    zone "local.example.com" {
      type master;
      file "/var/lib/bind/local.example.com.hosts";
    };

    zone "1.168.192.in-addr.arpa" {
      type master;
      notify no;
      file "/var/lib/bind/192.hosts";
    };
};

view "external" {
    match-clients { any; };

    zone "example.com" {
        type master;
        file "/var/lib/bind/example.com.external-hosts";
    };
};

Then in /var/lib/bind/example.com.external-hosts you have your origin, SOA and an include statement eg

$ORIGIN example.com
$TTL 600 ; 10 minutes
example.com.   IN SOA  ns1.example.com. hostmaster.example.com. (
        2021042801 ; serial
        10800      ; refresh (3 hours)
        3600       ; retry (1 hour)
        604800     ; expire (1 week)
        600      ; minimum (1 day)
        )

$INCLUDE "example.com.hosts";

The include line is relative to the the root directory you've set for bind so you might need to experiment with adding /var/lib/bind/

Your internal file would be similar, but with the extra entries

$ORIGIN example.com
$TTL 600 ; 10 minutes
example.com.   IN SOA  ns1.example.com. hostmaster.example.com. (
        2021042801 ; serial
        10800      ; refresh (3 hours)
        3600       ; retry (1 hour)
        604800     ; expire (1 week)
        600      ; minimum (1 day)
        )

ns1.local IN A  192.168.1.3
local     IN NS ns1.local.example.com.
$INCLUDE "example.com.hosts";

with the example.com.hosts file being stripped of origin or SOA eg

localhost   IN A    127.0.0.1
localhostv6 IN AAAA ::1

Try to avoid a ns1.local.example.com if you can avoid it as it requires a glue record because the host is within the domain it is serving.

You can skip the include and maintain the dns records in 2 different files, however they will drift and then you'll be in a bunch of pain trying to clean it up later. If you have multihomed hosts eg www on both public and private IPs then exclude it from the common file and add it to the 2 separate files with the different records.

score 0 · Answer 2 · answered Apr 27 '21 at 23:08

You need to have the main zone also defined differently in the internal view so that it has the delegation while the version in the external view doesn't have the delegation.

With things like that be however prepared with a lot of troubleshooting to do. If a single application or user is not matched by the internal view, it won't get the delegation and hence things will break and you might lose a lot of point pinpointing that because, internally, you will see the delegation.

Not knowing any specifics of your use case it is difficult to provide good advices, but using two separate domains might just be simpler.

PS: if you really need to obfuscate, please don't do it blindly, and stop using any random name you invent, just use example.com.

bind9 separated zone file for *.sub.domain.com

2 Answers2