Dear all,
I am deploying a DNS system using the Knot DNS software.
I have read in the document and I did not see any DNS query log.
So let me ask DNS Knot software can collect DNS query log? If possible,
what is the configuration?
Best regards,
Chinhlk.
Hi,
I performed a manual key roll over with this command:
$ knotc zone-key-rollover dnssec-test.xxx zsk
The result is 2 different ZSK's with the same key id:
dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 (
AwEAAc5W.....
) ; ZSK; alg = RSASHA256; key id = 7030
dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 (
AwEAAc7Q5U......
) ; ZSK; alg = RSASHA256; key id = 7030
>From the log:
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 56464,
algorithm RSASHA256, KSK, public, ready, active+
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030,
algorithm RSASHA256, public
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030,
algorithm RSASHA256, public, active
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, signing started
2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, zone is up-to-date
Is it the indented behavior to have two ZSK's with the same key id?
Thanks a lot,
Thomas
Hi all,
we'd like to inform you about recently found bug in Knot DNS 2.9.x.
The bug affects automatic key roll-overs when automatic key management
is configured
https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#automatic-dnssec-sig…
The ZSK, CSK or algorithm roll-over might be finished too early, so that
DNSKEY and RRSIG records in resolvers' caches get out of sync, leading
to temporary DNSSEC validation failure.
Affected versions are Knot DNS 2.9.0 -- 2.9.4.
We will release fixing version 2.9.5 soon.
In the meantime, we recommend to apply the workaround: set the
configuration option zone-max-ttl
https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#zone-max-ttl
explicitly to a value greater or equal to maximal TTL among all records
in the zone. (Remove the workaround once upgraded to fixed version.)
Many thanks to Anand Buddhdev from RIPE NCC for finding this bug.
Caring regards,
Libor Peltan
CZ.NIC
We're consolidating servers, and as a result. I need to transfer
some the IPs, zones && keys to other servers.
I'm trying to find the least eventful way to accomplish this.
I attempted to transfer (signed) zones and IPs once before. But
the slaves wouldn't accept the zones and I ultimately had to
purge the journals on all the servers I had control of, and
re-key and re-sign the zones to make everything work as intended.
All the zones are written/kept on disk (except changes that haven't
already been flushed to disk from the DB).
I'm wondering if it's enough to freeze all the zones on their
current serves. Then shutdown the server(s), and transfer the
zones, keys, and merge the configs onto the new servers would
be the correct way to do this? If not. Please advise.
Thank you for all your time, and consideration.
--Chris
Hi,
I've setup knot to AXFR 24 zones from our MS domain controllers but
three zones fail mysteriously. After enabling debug logging
knot adds additional line with the reason - 'trailing data'.
In the pcap file created with tcpdump I see that our server starts to
send TCP resets in the middle of the transfer.
Each time resets are sent after downloading approximately the same
amount of data, this amount differ for each zone (81kb for one, 49kb for
the second).
I am able to download the zone with dig or kdig. We also have a
different server with powerdns which is able to download the zones
without problems.
I've also tried to setup different server (with bind9) serving one of
the zones and have knot to download it from there. It worked just fine.
I can send the log file snippet (with zone name and ip addresses) as
well as the pcap file off the record.
Could you, please, help me with solving this problem?
Thank you,
Petr Baloun
Je dobré vědět, že tento e-mail a přílohy jsou důvěrné. Pokud spolu jednáme o uzavření obchodu, vyhrazujeme si právo naše jednání kdykoli ukončit. Pro fanoušky právní mluvy - vylučujeme tím ustanovení občanského zákoníku o předsmluvní odpovědnosti. Pravidla o tom, kdo u nás a jak vystupuje za společnost a kdo může co a jak podepsat naleznete zde<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>
You should know that this e-mail and its attachments are confidential. If we are negotiating on the conclusion of a transaction, we reserve the right to terminate the negotiations at any time. For fans of legalese—we hereby exclude the provisions of the Civil Code on pre-contractual liability. The rules about who and how may act for the company and what are the signing procedures can be found here<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>.
Hi,
I noticed that when using e.g the GeoIP module to return a CNAME, that
CNAME does not get resolved, even if it is within the instances
authority. That forces the client/recursor to issue another request.
Perusing the code for a while, I noticed that there is a rather simple
way to achieve this: the GeoIP module, if the result is a CNAME, _could_
set `qdata->name` to the CNAME target and return
`KNOT_IN_STATE_FOLLOW` instead of `KNOT_IN_STATE_HIT`.
While that does seem to work, I am not so sure if it might constitute an
abuse of interfaces. Returning `KNOT_IN_STATE_FOLLOW` seems legit, but I
wasn't so sure about modifying `qdata` (specifically, in the context of
a module).
As such, I would be interested if this has ever come up before, what
possible approaches might look like, what you think of the above one,
and if tackling this problem is of interest at all. If I have a better
understanding and there is a good approach to this, I'd be happy to
submit a patch.
Thanks a lot,
Conrad
Hello,
OS: CentOS 7.6
Knot: knot-2.9.3-1.el7.x86_64
I am trying to run knot DNS using maxmind GeoIP and it works well.
Now I also want it to be able to do weighted on those answers.
E.g. If country US, it will provide 3 answers and those will be weighted.
Is that correct and possible?
Thanks
Avinash
