Hello guys,
there has been a request in our issue tracker [1], to enable
IPV6_USE_MIN_MTU socket option [2] for IPv6 UDP sockets in Knot DNS.
This option makes the operating system to send the responses with a
maximal fragment size of 1280 bytes (minimal MTU size required by IPv6
specification).
The reasoning is based on the draft by Mark Andrews from 2012 [3]. I
wonder if the reasoning is still valid in 2016. And I'm afraid that
enabling this option could enlarge the window for possible DNS cache
poisoning attacks.
We would appreciate any feedback on your operational experience with DNS
on IPv6 related to packet fragmentation.
[1] https://gitlab.labs.nic.cz/labs/knot/issues/467
[2] https://tools.ietf.org/html/rfc3542#section-11.1
[3] https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01
Thanks and regards,
Jan
Hi All,
I built Knot 2.4.1 rpm and tried it on CentOS7. The server isn't reading
any of our zones with an error of:
"failed to load persistent timers (invalid parameter)"
Therefore it won't accept any notifies form master and won't read or
transfer any zone. Even when I do "knotc refresh ZONE" it will fail
saying zone is unknow.
This is an upgrade from Knot 2.2, and same configs doesn't complain
about anything and the server starts fine using that version, and load
zones, and respond to DNS queries without a problem.
I tried to find a procedure for a first time install for Knot and see if
there is any required initialization that needs to be done but no luck.
Have anyone tried Knot 2.4.1 with CentOS 7 please and successfully had
it running?
Note that I tried:
knotc conf-check (responds with: Configuration is valid)
knotc conf-read (shows all zones and template configs being read and
doesn't show any warning or error)
knotc conf-init
knotc conf-import /etc/knot/knot.conf
Either one of those will generate confdb. However, conf-init generates
it but then Knot doesn't show anything in the logs (set to debug), but
does generate timers folder.
But conf-import show same logs with same errors above, and still won't
load any of our zones.
I'm using these template settings:
""
mod-rrl:
- id: default
rate-limit: 200 # Allow 200 resp/s for each flow
slip: 2 # Every other response slips
template:
- id: default
storage: /var/lib/knot/zones
journal-db: journals
timer-db: timers
zonefile-sync: 60
semantic-checks: on
global-module: mod-rrl/default
""
I'd appreciate any suggestion please.
I'm new to this list, so if this is not where I was suppose to send this
please accept my apologize.
Thanks,
Kareem.
--
Abdulkareem H. Ali
Network Operations Engineer
CentralNic Group PLC
London Stock Exchange Symbol: CNIC
+44 20 3388 0600
www.CentralNic.com
CentralNic Group PLC is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R
6AR.
Dear all,
I'm setting up my own DNS and was not fund of the Idea to use bind. Then
someone pointed me to knot which ich immediatly found interresting.
After first successes I ran today into an error I could not resolve -
neither find anything on the web.
Finally I found this [1].
Is there a strong reason why you get specific modules only if you
compile knot yourself ?
For me I'm sad to say this is a no-go. I want to rely on automatic
updates for security.
Any chance this will be fixed ?
best regards
Dirk
[1] https://lists.nic.cz/pipermail/knot-dns-users/2017-January/001039.html
Dear Knot Resolver users,
a bugfix release of Knot Resolver 1.2.3 has been released.
The release contains following bugfixes:
- Disable storing GLUE records into the cache even in the
(non-default) QUERY_PERMISSIVE mode
- iterate: skip answer RRs that don't match the query
- layer/iterate: some additional processing for referrals
- lib/resolve: zonecut fetching error was fixed
The update from 1.2.2 to 1.2.3 is recommended. The update from 1.1.x
to 1.2.x branch is strongly recommended.
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.3/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/latest/
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
Hi,
We would like to enable ECS responses in our Knot server in order to
indicate to recursives that they should send it in requests if they can. The
goal is gauge how widespread usage of this feature this is and to collect
some statistics on the client networks being transmitted. We don't have a
way of providing tailored responses yet (not sure how this would be done,
but that's another topic.) Is there a way of enabling ECS so that it's
included in responses, perhaps with a scope prefix-length of 0 (as
described in section 12.1 of draft-ietf-dnsop-edns-client-subnet-08)?
Thanks,
Chuck
Dear Knot DNS users,
CZ.NIC is proud to release the 2.4.1 release of Knot DNS. This release
contains many improvements over 2.3.x release of Knot DNS.
The Knot DNS 2.4.x is the new stable branch. Starting from this release
we are going to support current stable (2.4.x) and previous stable (2.3.x)
branches, and at the same time we are deprecating previous Knot DNS 1.6.x
release.
This is a bugfix release containing small fixes, but the upgrade is
recommended.
And that's it! Thank you for using Knot DNS. And we are really looking
forward to your feedback.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.4.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.4.1.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.x/html/
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
Hello, all
When using knot DNS resolver, the following error was output.
Feb 06 20:19:43 dns02 kresd[24857]: error: /usr/lib/knot-resolver/predict.lua:34: 'struct rr_type' has no member named 'nil'
$ kresd -V
Knot DNS Resolver, version 1.2.1
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Is it related to setting reorder_RR (true)?
Is this a configuration issue in this case? Or is it a known bug?
Thanks.
Hi,
Is there any chance to configure the mod-dnsproxy to forward all requests for only one zone to another dns server?
I have this configuration in bind configuration file:
zone "example.com" IN {
type forward;
forwarders {
1.2.3.4;
};
};
Is there any way to do it in knot?
Best regards,
