bind (plugin): specify slave zones?

[defaultuserfoo]

Hi,

how can I specify slave zones?  The bind plugin doesn't seem to have options for that.  I wouldn't mind editing some configuration files directly, but I wouldn't want such changes automatically overwritten.

PS: Is that what the secondary zones are for?  I haven't heard that term before.

[Patrick M. Hausen]

master == primary
slave == secondary

The master/slave terminology is phased out from most open source projects for obvious reasons. E.g. github switched the "master" branch to "main" by default.

[defaultuserfoo]

master == primary
slave == secondary

The master/slave terminology is phased out from most open source projects for obvious reasons. E.g. github switched the "master" branch to "main" by default.

Thanks!  I don't see how it would be obvious, though, and I haven't used git much recently.

And it's not really working (yet).  The zone files that are being created are what I'd call malformed, and I'm even getting errors like

Code: [Select]

02-Oct-2023 22:07:00.461 general: error: dns_rdata_fromtext: /usr/local/etc/namedb/primary/example.org.db:4: near eol: unexpected end of input
in /var/log/named/named.log.  I have pretty zone files like

Code: [Select]

$TTL 3D
@       IN      SOA     host1.example.org.        root.example.org. (
                                                39
                                                8H
                                                2H
                                                4W
                                                1D )
                NS      host1
                MX      10 host1

host1           A       192.168.3.50
host1           AAAA    fd53::11

with quite a few entries.  I'd rather copy that over from my current name server than adding all the entries manually.  The GUI creates malformed files like this:

Code: [Select]

# less /usr/local/etc/namedb/primary/example.org.db
$TTL 86400
@       IN      SOA    bitfrost.example.org. root.example.org. ( 2310022206 21600 3600 3542400 3600 )
host1                A 192.168.3.1
host1                NS 
host1                AAAA fd53::11

That's ugly, and I'm not sure how to fix it.  Can I just copy the existing files, make the necessary modifications, and the bind plugin will be able to read them?

The NS record is obviously wrong ...


PS: After a while, it occurred to me that I may be able to create the NS entry the other way round, and that does give a better record.  Now it seems to be working.  Now that's great

[Patrick M. Hausen]

I don't see how it would be obvious, though

You don't see how "master" and "slave" could be problematic terms in today's political environment?

As for your technical problems I would need to see your configuration for a secondary zone to give any further advice.

Kind regards,
Patrick

[defaultuserfoo]

I don't see how it would be obvious, though

You don't see how "master" and "slave" could be problematic terms in today's political environment?

No, what's the problem?  What has politics to do with it?

As for your technical problems I would need to see your configuration for a secondary zone to give any further advice.

I don't have a configuration yet except for what I have on my current name server.  I only just found out about the bind plugin and decided to check it out.  I'll make real changes only later after moving opnsense from a VM to actual hardware.

Do you have any idea how to create SRV records through the GUI?

[Patrick M. Hausen]

You don't see how "master" and "slave" could be problematic terms in today's political environment?

No, what's the problem?  What has politics to do with it?

Seriously? People being triggered by some technical artifact being named "slave"? Where have you been living?

Do you have any idea how to create SRV records through the GUI?

Sure, see screen shot - of course you can only create entries in master/primary zones.

Kind regards,
Patrick

[defaultuserfoo]

You don't see how "master" and "slave" could be problematic terms in today's political environment?

No, what's the problem?  What has politics to do with it?

Seriously? People being triggered by some technical artifact being named "slave"? Where have you been living?

Seriously.  What's wrong with these people?  Zone entries in the configuration of DNS servers aren't a technical artifact anyway.

Besides, 'primary' and 'secondary' is nonsense.  Technically, they are all master zones; the difference is that master zones are local, or 'native' if you want to call it that way, while the DNS server acts as a slave by getting zones from and serving zones on behalf of another DNS server which is therefore called 'master'.  So you could call them maybe 'local', or 'native', and 'foreign', or 'alien', zones, but not 'primary' or 'secendary'.  'Secondary' even indicates that there might be 'tertiary', and so on, zones, and that makes it confusing.  However, 'master' and 'slave' zones are evident, and there's no reason for changing their naming.

Do you have any idea how to create SRV records through the GUI?

Sure, see screen shot - of course you can only create entries in master/primary zones.

Thanks, that works

[passeri]

@defaultuserfoo, let's get the politics out of it. A secondary server gives authoritative answers. It will continue to do so if the primary drops permanently dead, there being no technical/configuration difference in that respect.
The secondary can be updated directly by the admin, even while a primary exists (if you do not mind a potential discrepancy) and will not be overridden unless the primary is updated. That overriding is solely a function of a selection of update direction (which you find more convenient to update directly) and trivial to switch around; nothing else.
For these reasons, ISC adopted the primary/secondary terminology as reflecting reality, where use of master/slave is misleading and futile. You will find that other people either have made or are making this change. It's in the docs.

[passeri]

...and thanks for raising the original topic of configuration of BIND on Opnsense, defaultuserfoo. It is something I am about to test myself.

[defaultuserfoo]

@defaultuserfoo, let's get the politics out of it. A secondary server gives authoritative answers. It will continue to do so if the primary drops permanently dead, there being no technical/configuration difference in that respect.

The remote server doesn't give any answers to the local server other than in response to zone transfer requests for those zones for which it is configured to transfer them when they have been requested.  It doesn't request anything from the local server unless the local server would be configured to answer requests from the remote server if the remote server were configured to send requests to the local one.

The secondary can be updated directly by the admin, even while a primary exists (if you do not mind a potential discrepancy) and will not be overridden unless the primary is updated. That overriding is solely a function of a selection of update direction (which you find more convenient to update directly) and trivial to switch around; nothing else.

Both the remote and the local server can be updated or not.  There's no discrepancy, and nothing gets overridden.

Something might be overriden, or discrepancies could be created, if the both the local and the remote server were both authortitative for the same zones.  If they were, that would be a misconfiguration, or weren't it?

For these reasons, ISC adopted the primary/secondary terminology as reflecting reality, where use of master/slave is misleading and futile. You will find that other people either have made or are making this change. It's in the docs.

This is not reasons but invalid.  It's confusing and may be misleading.  Master/slave is evident and not misleading, nor futile.

[Patrick M. Hausen]

The ISC changed the terms to primary and secondary with BIND 9 and there is no arguing about that fact. Probably you missed the memo.

[defaultuserfoo]

The ISC changed the terms to primary and secondary with BIND 9 and there is no arguing about that fact. Probably you missed the memo.

Well, I didn't get a memo.  I'm not argueing about that they decided to use different words for the same thing.  I'm only saying that they should have picked better words and that they shouldn't have picked different ones to begin with.


PS:  I think you're right about the 'technical artifact'.  I keep forgetting that 'artifact' in English doesn't mean 'artifact' as in something that is very old, and that it means something artifically created instead.

[defaultuserfoo]

...and thanks for raising the original topic of configuration of BIND on Opnsense, defaultuserfoo. It is something I am about to test myself.

It'll be a while before I can make the change here.  If you can read/understand bind configuration files, you should be fine.  If you want to look at them, they're under /usr/local/etc/namedb.

[passeri]

@defaultuserfoo: Yes, I can read a BIND file OK thanks. I approach new platforms cautiously. We have had BIND ticking away on prior servers for over a decade.

I see that my 2006 edition of “DNS & BIND” refers to Primary and Secondary. That will do.