Subject: GUI Frontends for Knot DNS Server
Good day from Singapore,
Are there any GUI frontends for configuring Knot DNS Server?
I prefer GUI configuration interface. It is more efficient than
command line interface (CLI).
Thank you.
Regards,
Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
Blogs:
https://tdtemcerts.blogspot.comhttps://tdtemcerts.wordpress.com
Hello,
Running knot-resolver 5.6.0-1 amd64 (latest available via apt) on
debian-12 bookworm, fully upgraded.
systemctl start kresd@1 fails to run.
systemctl status kresd@1 shows the following errors:
[system] error while loading config:
...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad
argument #1 to 'create' (table expected, got nil) (workdir
'/var/lib/knot-resolver')
Here is my kresd.conf. It had been running ok for a long time ( I don't
recall making any changes) :
- Default empty Knot DNS Resolver configuration in -*- lua -*-
-- Bind ports as privileged user (root) --
net = { '127.0.53.0' }
-- Switch to unprivileged user --
user('knot-resolver','knot-resolver')
-- Unprivileged
-- cache.size = 100*MB
policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains))
policy.add(policy.suffix(policy.STUB({'127.53.0.0'}), internalDomains))
policy.TLS_FORWARD({
-- multiple servers can be specified for a single slice
-- the one with lowest round-trip time will be used
{'9.9.9.9', hostname='dns.quad9.net'},
{'149.112.112.112', hostname='dns.quad9.net'},
})
All help is greatly appreciated,
Mike Wright
Dear mailing list subscribers,
due to a subtle bug in our mailing list processing system, a few emails
sent to the mailing list <knot-dns-users(a)lists.nic.cz> over the past two
years were blocked and awaiting approval without our knowledge. After
filtering out spam, we will review what we believe is still relevant and
reach out to the senders directly in the coming days.
If your email did not pass through the moderation phase, please resend
it to the list after the middle of next week. We are sorry for this
issue.
Our thanks go to Juha Suhonen who helped us discover the problem by
pointing out that his email is still waiting. Thank you, Juha.
Best regards,
David Vašek, Knot DNS team
Hi,
I’m updating our config files and I’m wondering if we need to set ‘key’ in remotes section, and in acl section?
If I have this in my config:
remote:
- id: remote01
address: 127.0.0.1
key: my_key
acl:
- id: allow_transfer
address: 127.0.0.1
key: my_key
action: transfer
zone:
- domain: example.com
acl: [ allow_transfer ]
notify: [ remote01 ]
Couldn’t I just remove key attribute from the remote, since the acl declares the address and key that are allowed to transfer the zone?
.einar
Daniel Salzman wrote:
> Hello Knot DNS users,
>
> CZ.NIC has released Knot DNS 3.3.2!
>
> This version fixes various issues and introduces some features regarding IXFR.
> Users of PKCS #11 keystore might appreciate improved signing performance using more thread.
>
> Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side!
>
> Changelog:
> https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS
Hi,
I'm interested in this change:
- knotd: failed to sign RRSet that fits to 64k only if compressed
Which seems to be this commit:
https://gitlab.nic.cz/knot/knot-dns/-/commit/f55037f6f39d0ddf6debac47fe168d…
"libknot/knot: allow uncompressed wire conversion of rrset that fits to
64k only when compressed"
It's not totally clear to me, but it seems like this would allow an
RRset (or individual RR, if the number of RRs in the RRset is 1?) that,
exceeds 64K, if name compression would reduce the size on the wire to
<64K? (And the 64K isn't measured by just the RDATA/RDLEN fields, but
rather the whole wire serialization of the record set, including owner
name, type, class, TTL, etc.)
If so, is this a safe and/or interoperable thing to do? DNS
implementations are required to implement decompression, but compression
is optional (RFC 1035 § 4.1.4). So a resolver might receive a compressed
RRset, decompress it, and then be unable to represent that RRset to
clients if it doesn't implement compression, or, more likely, implements
compression but uses an algorithm that generates less optimal
compression targets than the one used by the original nameserver.
Or am I misunderstanding what this commit is doing?
Thanks!
--
Robert Edmonds
edmonds(a)debian.org
