Opened 4 years ago

Last modified 3 years ago

#62494 assigned defect

dns-server can create a duplicate "domain" zone in named.conf

Reported by: steven-michaud (Steven Michaud) Owned by: essandess (Steve Smith)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: dns-server

Description (last modified by steven-michaud (Steven Michaud))

I've used dns-server to install and configure bind9 on a test server on my local (private) network. Its domain name includes the "private" TLD -- "bagend.private". "named.conf.macports" contains the following two "zones":

zone "@domain@.private" IN {
        type master;
        file "db.@domain@.private";
        allow-transfer {
                none;
        };
        allow-update {
                none;
        };
};
zone "@domain@.@tld@" IN {
        type master;
        file "db.@domain@.@tld@";
        allow-transfer {
                none;
        };
        allow-update {
                none;
        };
};

On my system this results in two identical zones being created in "named.conf". This is an error, and bind9 refuses to load until I remove one of them.

I'm working on macOS 11.2.3. My MacPorts bind9 distro is "bind9 @9.16.12".

Change History (10)

comment:1 Changed 4 years ago by steven-michaud (Steven Michaud)

Description: modified (diff)

comment:2 Changed 4 years ago by jmroot (Joshua Root)

Owner: set to essandess
Status: newassigned

comment:3 Changed 4 years ago by essandess (Steve Smith)

Steven, Thank you for posting these dns-server issues.

For context, dns-server is intended to provide a basic, vanilla, bind9 configuration that users will modify for their own networks.

The install process should create a named.conf file with settings inferred from your local network at the time of install, apply them to the template named.conf.macports, and if it gets it wrong, then one has to edit named.conf to fix and/or modify things to suit your own network. You own the named.conf file, and MacPorts owns the named.conf.macports template file.

I’m pretty sure that bind9 will throw an error if it’s fed the raw named.conf.macports file with those @ signs and without any substitutions for @tld@ and so forth. Is that what you’re seeing?

If you edit in actual domain.tld values, this named.conf file works.

comment:4 Changed 4 years ago by steven-michaud (Steven Michaud)

You're not addressing the issue I reported. I was definitely not using the raw named.conf.macports file. I was using a file generated from it by dns-server's script(s). It had two identical "bagend.private" zones.

Last edited 4 years ago by steven-michaud (Steven Michaud) (previous) (diff)

comment:5 Changed 4 years ago by steven-michaud (Steven Michaud)

I should add that I'm already running my own local DNS server (the one from macOS Server 5.3.1 running on macOS 10.12.6) on my local network. In that environment my test server ("frankenserver") has a full hostname (i.e. "frankenserver.bagend.private"), including a "domain" and a "tld". That probably wouldn't have been the case if I hadn't already been running a DNS server. In that case the test machine's hostname would presumably have been something like "frankenserver.local". And I probably wouldn't have ended up with two identical "bagend.private" zones in the named.conf generated by dns-server's script(s).

So this bug is a special case, and not as important as I first thought. Still, though, it'd be nice if you could add a workaround for this special case.

comment:6 Changed 4 years ago by steven-michaud (Steven Michaud)

Yet one more thing, in case it comes up:

Before I installed dns-server I changed my test server's network settings. I set the IP address "manually", using one not from the range provided by my local DHCP server (also from macOS Server 5.3.1). I set the "search domains" and "DNS servers" to what had previously provided by the DHCP server. And I updated my test machine's IP address on my network's DNS server (and removed it from my DHCP server). And before I loaded bind9 for the first time I manually set the machine's "DNS servers" to "127.0.0.1" and "::1".

My test server's bind9 implementation is now running just fine. I'm not yet using it for my whole network -- just on my test server.

Last edited 4 years ago by steven-michaud (Steven Michaud) (previous) (diff)

comment:8 Changed 4 years ago by essandess (Steve Smith)

In a64f314af5027bb61029934910664906113c5aa1/macports-ports (master):

dns-server: Update to version 9.16.13 with bugfixes and improvements

comment:9 Changed 4 years ago by steven-michaud (Steven Michaud)

A few hours after this bug's fix landed (as per comment 8) I tested it as follows:

  1. I ran sudo port selfupdate and sudo port upgrade outdated to make sure I had the latest version of everything MacPorts.
  1. I sudo port uninstalled both dns-server and bind9. I also removed all the files dns-server had created.
  1. I reran sudo port install dns-server.

I saw the appropriate warning in my Terminal screen about having a duplicate 'bagend.private' zone.

It'd have been nice if you could have programmatically have avoided creating the duplicate. But, as you say, people will still need to edit various files by hand. So your fix is certainly acceptable.

Thanks for fixing this so quickly!

comment:10 Changed 3 years ago by essandess (Steve Smith)

This issue is fixed by https://github.com/macports/macports-ports/pull/10342 and may be closed.

Note: See TracTickets for help on using tickets.