6 Čec
2023
6 Čec
'23
20:51
Hi Knotty people,
I've started uprading my infrastructure to Debian 12 which comes with knot
3.2.6 (instead of 3.0.5) and since the upgrade my catalog zone
configuration doesn't seem to work anymore.
I have this in knot.conf:
zone:
- domain: dxld.catalog
catalog-role: interpret
catalog-template: dxld-master
template: dxld-master
dxld.catalog gets loaded properly, `knotc zone-read dxld.catalog`:
[dxld.catalog.] dxld.catalog. 0 SOA ns0.dxld.at. hostmaster.dxld.at. 2023070601 900 300
86400 300
[dxld.catalog.] version.dxld.catalog. 0 TXT "2"
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.at.
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.net.
[dxld.catalog.] zones.dxld.catalog. 0 PTR darkboxed.org.
but the zones pointed to don't get instantiated (as seen by `knotc
zone-status`). Any ideas what could have changed to break this?
Thanks,
--Daniel
7 Čec
7 Čec
11:49
Hi Daniel,
could you please share what the log says when Knot loads the catalog
zone and possibly tries to load the members? The settings of dxld-master
template can be useful too, if possible. Thanks.
Regards,
David
On 2023-07-06 20:51, Daniel Gröber wrote:
Hi Knotty people,
I've started uprading my infrastructure to Debian 12 which comes with
knot
3.2.6 (instead of 3.0.5) and since the upgrade my catalog zone
configuration doesn't seem to work anymore.
I have this in knot.conf:
zone:
- domain: dxld.catalog
catalog-role: interpret
catalog-template: dxld-master
template: dxld-master
dxld.catalog gets loaded properly, `knotc zone-read dxld.catalog`:
[dxld.catalog.] dxld.catalog. 0 SOA ns0.dxld.at.
hostmaster.dxld.at. 2023070601 900 300 86400 300
[dxld.catalog.] version.dxld.catalog. 0 TXT "2"
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.at.
[dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.net.
[dxld.catalog.] zones.dxld.catalog. 0 PTR darkboxed.org.
but the zones pointed to don't get instantiated (as seen by `knotc
zone-status`). Any ideas what could have changed to break this?
Thanks,
--Daniel
--
12:20
On Thu, 6 Jul 2023 20:51:04 +0200
Daniel Gröber <dxld(a)darkboxed.org> wrote:
but the zones pointed to don't get instantiated
(as seen by `knotc
zone-status`). Any ideas what could have changed to break this?
Your catalog zone doesn't follow proper catalog format. you should have
uniqueid per zone. so format is:
<uniqueid>.zones.<catalog-zone>. 0 PTR domain.tld.
you can select any method to generate uniqueid. We originally decided
to use uuid but after initial testing we moved to md5sum of
"domain.tld.primary.server.dns-name." so we can re-generate always same
uniqueid. Problem with uuid was we'd need to have separate database to
store uuid domain.tld. combinations. you could use any "salt" instead
of primary.server.dns-name. but for our purposes server dns name was
unique.
Some kind of hash of domain is not enough in case you need to handle
moving domain from one system to another where catalog interpreter can
be secondary server for multiple different primary servers.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
12:31
Yes, it is likely that the missing unique-id's are the only problem. I
was able to reproduce the issue with that setup - I'm quite surprised
that such a faulty catalog zone actually worked with 3.0.5.
So, Daniel, try adding the unique-id's first.
Regards,
David
On 2023-07-07 12:20, Tuomo Soini wrote:
On Thu, 6 Jul 2023 20:51:04 +0200
Daniel Gröber <dxld(a)darkboxed.org> wrote:
but the zones pointed to don't get
instantiated (as seen by `knotc
zone-status`). Any ideas what could have changed to break this?
Your catalog zone doesn't follow proper catalog format. you should have
uniqueid per zone. so format is:
<uniqueid>.zones.<catalog-zone>. 0 PTR domain.tld.
you can select any method to generate uniqueid. We originally decided
to use uuid but after initial testing we moved to md5sum of
"domain.tld.primary.server.dns-name." so we can re-generate always same
uniqueid. Problem with uuid was we'd need to have separate database to
store uuid domain.tld. combinations. you could use any "salt" instead
of primary.server.dns-name. but for our purposes server dns name was
unique.
Some kind of hash of domain is not enough in case you need to handle
moving domain from one system to another where catalog interpreter can
be secondary server for multiple different primary servers.
13:09
Hi Tuomo and David,
On Fri, Jul 07, 2023 at 12:31:50PM +0200, David Vasek wrote:
Yes, it is likely that the missing unique-id's are
the only problem. I was
able to reproduce the issue with that setup - I'm quite surprised that such
a faulty catalog zone actually worked with 3.0.5.
So, Daniel, try adding the unique-id's first.
Yeah that did it. Not sure how I missed that, I was read over that bit in
the docs like three times :)
When I set this up I was probably just too lazy to assign IDs and was happy
when it worked without.
On 2023-07-07 12:20, Tuomo Soini wrote:
you can select any method to generate uniqueid. We
originally decided
to use uuid but after initial testing we moved to md5sum of
"domain.tld.primary.server.dns-name." so we can re-generate always same
uniqueid. Problem with uuid was we'd need to have separate database to
store uuid domain.tld. combinations. you could use any "salt" instead
of primary.server.dns-name. but for our purposes server dns name was
unique.
Some kind of hash of domain is not enough in case you need to handle
moving domain from one system to another where catalog interpreter can
be secondary server for multiple different primary servers.
I write the catalog zone by hand so hashing or whatnot is a big hassle, for
now I'll just go with a-z then. AFAIU this shouldn't be a problem since I
don't do dnssec signing and don't care if zone state is purged in the
future.
Thanks,
--Daniel
19:31
Hi,
The implementation of catalog zones in Knot DNS 3.0.x isn't mature
enough, and it doesn't fully comply with the fresh RFC
https://www.rfc-editor.org/rfc/rfc9432.html, which was released yesterday.
Daniel
On 07. 07. 23 13:09, Daniel Gröber wrote:
Hi Tuomo and David,
On Fri, Jul 07, 2023 at 12:31:50PM +0200, David Vasek wrote:
Yes, it is likely that the missing
unique-id's are the only problem. I was
able to reproduce the issue with that setup - I'm quite surprised that such
a faulty catalog zone actually worked with 3.0.5.
So, Daniel, try adding the unique-id's first.
Yeah that did it. Not sure how I missed that, I was read over that bit in
the docs like three times :)
When I set this up I was probably just too lazy to assign IDs and was happy
when it worked without.
On 2023-07-07 12:20, Tuomo Soini wrote:
you can select any method to generate uniqueid.
We originally decided
to use uuid but after initial testing we moved to md5sum of
"domain.tld.primary.server.dns-name." so we can re-generate always same
uniqueid. Problem with uuid was we'd need to have separate database to
store uuid domain.tld. combinations. you could use any "salt" instead
of primary.server.dns-name. but for our purposes server dns name was
unique.
Some kind of hash of domain is not enough in case you need to handle
moving domain from one system to another where catalog interpreter can
be secondary server for multiple different primary servers.
I write the catalog zone by hand so hashing or whatnot is a big hassle, for
now I'll just go with a-z then. AFAIU this shouldn't be a problem since I
don't do dnssec signing and don't care if zone state is purged in the
future.
Thanks,
--Daniel
--
306
days inactive
307
days old
5 comments
4 participants
participants (4)
-
Daniel Gröber -
Daniel Salzman -
David Vasek -
Tuomo Soini