Hello,
I'm not sure I'm posting in the right place. Don't hesitate to tell me
if it's not.
I began to test the use of Knot Resolver 6.x for a future project
(deploying a DNS resolver with blocked domains lists).
I would like to know if it's possible to split the config.yaml in
several files (the main config in one file, acl and views section in
another, data-local section with rpz lists and tags to rely acl lists to
blocklists in another), and if the answer is yes, how can I do ?
Thank you for your help.
Regards,
Stephane
I ultimately found that I needed to use a CH in KDIG but wonder how I/We could update the documentation or add an alias for chaos.
Working Example:
dig +short @<dns server> version.bind chaos txt
dig +short @<dns server> version.bind CH txt
kdig +short @<dns server> version.bind CH txt
Problem Example:
kdig +short @<dns server> version.bind chaos txt
I had to read source code to find the answer in a speedy timeframe.
Hi,
for benchmark purpose I need to find out how log it takes to sign zone
files in different sizes with different hardware. What is the best way
to find out the exact time the signing process takes?
Thanks!
BR
Thomas
Hi,
when signing a zone file I receive this error in the log:
"zone event 're-sign' failed (not enough space provided)"
Can you tell me what is the limiting factor here?
Thanks!
BR
Thomas
Hello,
Could you please clarify whether Knot can perform a zone transfer not
from the first master listed, but from the one that sent the NOTIFY? The
masters are configured in the following order:
remote:
- id: master
address: [ "192.168.58.151", "192.168.58.134" ]
When a NOTIFY is sent from |192.168.58.134|, the zone transfer is still
performed from |192.168.58.151|.
Here are the relevant log entries:
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] notify,
incoming, remote 192.168.58.134@32888 TCP, serial 2006
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] refresh, remote
192.168.58.151@53, remote serial 2006, zone is outdated
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] IXFR, incoming,
remote 192.168.58.151@53 TCP, receiving AXFR-style IXFR
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] AXFR, incoming,
remote 192.168.58.151@53 TCP, started
Thank you for your product and for your help!
*Best regards,*
*A.A. Basov*
Hi,
this happened to me for the second time, that https://dnsviz.net <https://dnsviz.net/> tells me:
| enfer-du-nord.net/CDNSKEY: The CDNSKEY RRset must be signed with a key that is represented in both the
| current DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1.
| enfer-du-nord.net/CDS: The CDS RRset must be signed with a key that is represented in both the current
| DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1.
I do not understand what that means.
#) I haven't modified my KSK for some time now
#) I did notify my parent zone about a modified list of nameservers (via registrar's web portal)
I am not absolutely sure if the latter is the cause for these error messages.
I 'fixed' that issue by re-uploading my unmodified KSK DNSKEY (via registrar's web portal).
Hmm, how can I fix that issue the right way?
Any hints are highly welcome,
Michael
Hi,
given the case that a ip6/xy block might be delegated to me by my ISP, I began investigating Knot DNS' functionality with regard to ip6.arpa.
Hereby I stumbled over the module synthrecord and do not really understand what it is used for.
From https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#synthrecord-automati…
"Records are synthesized only if the query can't be satisfied from the zone."
Please excuse my ignorance, but why would/should/must one return something else than the following for hosts not in the zone?
kbn> host 2001:dead:beef::1
Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
Any feedback is highly appreciated, thanks.
Regards,
Michael
Hi,
This is just a possible feature request. We’re planning on using Knot for user
hosted domains. To do that we’ll have to add and remove zones dynamically,
so we’ve enabled the config db.
What surprised us is that this means that the config file isn’t used at all anymore
(except you can use it to prime the config db).
As it is, we’ll have to embrace the config db, which makes our ansible playbook
more complicated. It’s easy to add a config file template in ansible, it’s more
complicated to issue `knotc conf-begin; knotc conf-set; knotc conf-commit` logic.
I wish knot was more like nsd, where you have the config file nsd.conf, but if
you add zones with `nsd-control addzone ….` it gets added to a seperate zonelist
file, which nsd reads on startup. It means we can have a static config file, but
still be able to add and delete zones dynamically.
nsd doesn’t have automatic DNSSEC key management and catalog zones in knot
are really easy to use, which is why we’re going with knot for this project. I just
wanted to lay it out there as an idea for the future :)
.einar
