30 Čec
2025
30 Čec
'25
23:28
I am definitely interested in examples!
Reading up on groups, is it that 'group A' may represent 'customer A'
and have a specific set of Primary/Master nameservers, Group B ==
Customer B, different Primary, and so on?
(also fixed to be plain text - hope this is more legible in the archives)
--Chris
31 Čec
31 Čec
18:44
New subject: Catalog zones when secondary to other servers
Hi,
Exactly, one catalog group (configuration template) can represent one customer. Then you
can configure each template
with different master/notify/acl and so on.
I have realized that the catalog zone is generated by PDNS and I'm not sure if it
supports adding a group property.
We have an example in the documentation
https://www.knot-dns.cz/docs/latest/singlehtml/index.html#catalog-zones-con…
see the records starting with 'group' owner names.
You can configure notify for any remote server.
Daniel
On 7/30/25 23:28, Chris Wopat wrote:
I am definitely interested in examples!
Reading up on groups, is it that 'group A' may represent 'customer A'
and have a specific set of Primary/Master nameservers, Group B ==
Customer B, different Primary, and so on?
(also fixed to be plain text - hope this is more legible in the archives)
--Chris
--
19:28
New subject: Catalog zones when secondary to other servers
Thanks. I indeed asked a question that's half PowerDNS and half Knot.
It does look like PowerDNS lets you set group info on producer zones
(not consumer, which knot is doing):
* https://doc.powerdns.com/authoritative/catalog.html
So it sounds like I would have to do that when setting up a zone, map
a bunch of things. It sounds like I would have to define the group
data (Primary IP, etc) on Knot itsself, and not inherit this data via
Catalog Zones? I see that catalog zones have "custom extensions" but
PowerDNS doesnt support it (per link above).
It may just be simpler to call PowerDNS API and create a knot config
of all secondaries, which is fairly straightforward - but again
completely removes the need for catalog zones in my case. I would then
have:
1) zones of type Primary are using catalog
2) zones of type Secondary are using $myscript
From our provisioning perspective, at least it would all done the same
way - I would just have to determine more details with option 2 - like
how frequent to run, how to reload knot when done, etc.
Is this generally how others are doing this? Or are people only really
using Catalog zones for primaries, never secondaries?
Cheers,
--Chris
20:01
New subject: Catalog zones when secondary to other servers
The current catalog zones don't support storing configuration data such as
primary IPs. However, there is some work on this
https://github.com/DNS-Hackathon/catalog-extensions-draft/blob/main/draft-a….
Do I understand correctly that your customers store the primary IPs
to the database? So there are many and possibly non-static primary server?
You can only generate the catalog templates. Not full configurations with
all zones explicitly specified.
I know only catalog zone users with almost fixed configurations and
they use it on secondaries as well.
Daniel
On 7/31/25 19:28, Chris Wopat wrote:
Thanks. I indeed asked a question that's half
PowerDNS and half Knot.
It does look like PowerDNS lets you set group info on producer zones
(not consumer, which knot is doing):
* https://doc.powerdns.com/authoritative/catalog.html
So it sounds like I would have to do that when setting up a zone, map
a bunch of things. It sounds like I would have to define the group
data (Primary IP, etc) on Knot itsself, and not inherit this data via
Catalog Zones? I see that catalog zones have "custom extensions" but
PowerDNS doesnt support it (per link above).
It may just be simpler to call PowerDNS API and create a knot config
of all secondaries, which is fairly straightforward - but again
completely removes the need for catalog zones in my case. I would then
have:
1) zones of type Primary are using catalog
2) zones of type Secondary are using $myscript
From our provisioning perspective, at least it would all done the same
way - I would just have to determine more details with option 2 - like
how frequent to run, how to reload knot when done, etc.
Is this generally how others are doing this? Or are people only really
using Catalog zones for primaries, never secondaries?
Cheers,
--Chris
20:12
New subject: Catalog zones when secondary to other servers
Thanks for the draft link - glad folks realize this issue.
Correct on how Primaries are stored. If we have a customer we're
secondary to, we add the zone and the primary IP's they tell us (we
add all zones ourselves). Some have one zone and one primary. Some
have 30 zones but some zones have primary A and some have primary B.
Anyhow, I created a proof of concept script that will create Knot
secondary config from PowerDNS - note this isn't tested but seems
about right.
* https://gist.github.com/falz/b0f07945b5196a585d0fb1462467a8ea
Since the primary IPs vary, I had it create a 1:1 mapping of "remote:"
to "zone:". example output:
####################################
# zone: customera.com
# account: customera
# dnssec: False
remote:
- id: customera.com_primary
address: [10.227.254.23]
zone:
- domain: customera.com
master: customera.com_primary
####################################
# zone: mailer2.customerb.edu
# account: customerbuniv
# dnssec: False
remote:
- id: mailer2.customerb.edu_primary
address: [10.44.124.10]
zone:
- domain: mailer2.customerb.edu
master: mailer2.customerb.edu_primary
...
I may or may not go this route, still exploring options.
--Chris
10
days inactive
11
days old
4 comments
2 participants
participants (2)
-
Chris Wopat -
Daniel Salzman