Hi.
I have a KNOT master with a small zone (32 records), which is logging an
error after the secondary (BIND) tries to update the zone. AFAIK, Bind
tries with IXFR first, but my master says:
2016-08-19T16:32:12 error: [manojitos.cl] IXFR, outgoing,
200.1.123.7@29095: failed to start (not enough memory)
After that the secondary retries with AXFR, and that works:
2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing,
200.1.123.7@13644: started, serial 2016011013
2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing,
200.1.123.7@13644: finished, 0.00 seconds, 1 messages, 2573 bytes
The error is the same the first time I provision the zone in the
secondary as in following updates. Is there a bug in the error message,
or should I worry for some memory requirement in my server (or service)?
I'm with Knot 2.3.0 on a FreeBSD 10.3-release-p7. The secondary is not
under my administration, but I was told is Bind with an up-to-date
version.
Thanks!
Hugo
Dobry den,
zamyslame pouzit KNOT na DNS serveroch. Avsak potrebujeme k tomu aj
nejaky WEB GUI.
Disponujete niecim takym? Pripadne viete o nejakom pouzitelnom?
Na Vasej www stranke som to zatial zial nenasiel..
dakujem
--
Hello!
CZ.NIC just released a new version of Knot DNS. There are some bug fixes
and improvements as usual. But most of the changes are new features.
The bug fixes are mostly insignificant, so I'll make it quick:
- We have resolved a problem with NSEC-signed zones when a wildcard was
incorrectly expanded below a closer empty non-terminal.
- The checks on the incoming IXFR were improved so that we now refuse
transfers containing non-existing records to be removed. This problem
was identified in draft-song-dnsop-ixfr-fallback-01.
- The kdig utility can now correctly process IXFR response with empty
content (i.e. when the zone is up-to-date).
- The server now makes sure that PKCS #11 modules are not loaded
multiple times.
As for the improvements:
- The code for semantic checks was refactored and the error messages
should be a bit more readable.
- The TC flag setting in delegation is now set only if the mandatory
glue doesn't fit. Optional glue may not fit and the TC flag won't be
set See my e-mail "glue and TC flags revisited" for more details:
https://lists.nic.cz/pipermail/knot-dns-users/2016-June/000905.html
- With the new version, you can set different EDNS(0) payload size
for IPv4 and IPv6. See max-ipv4-udp-payload and max-ipv6-udp-payload
configuration options.
And now the interesting new stuff:
- DNSSEC policy can be now defined in the server configuration. This
makes automatic signing even easier to use. It's only a few lines
of the configuration file. Really. Please, have a look at the
"Automatic DNSSEC signing" section in the documentation.
For easy transition, if the policies are not defined in the server
configuration, the ones from the old KASP database are used instead.
The keymgr with the --legacy option can be used to maintain the old
policies.
The KASP database is still used to store signing state and private
key material. This might be changed in the future versions.
- We have added support for automatic NSEC3 resalting. For this
purpose, the new nsec3-salt-length and nsec3-salt-lifetime policy
options were added.
Please note that in the previous releases, the NSEC/NSEC3 mode
for DNSSEC signing was determined by the presence of NSEC3PARAM
record in the zone. This is no longer true. The nsec3 policy option
is used instead. Note that this option was already present in older
releases but it didn't work; please check your signing policies
before the upgrade.
- The control interface was extended to allow changing the zone content.
It's experimental, the changes are internally processed similarly to
DDNS which brings the same performance drawbacks, but we would like
to builds some more robust interface on top of this one.
- The zone size limit for DDNS, AXFR, and IXFR can be now enforced
using the max-zone-size option. The default is unlimited. This is
our solution for the CVE-2016-6171.
Please note that for IXFR, the effective limit for the total size of
the records in the transfer is twice the configured value. However
the final zone size must satisfy the limit fully.
- The kdig utility can talk TLS. Also EDNS(0) padding is supported.
Does your local resolver support DNS-over-TLS? Give it a try:
$ kdig +tls +alignment=512 www.knot-dns.cz
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.3.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz.asc
Best regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Hi everyone,
CZ.NIC is proud to release second production release of
Knot Resolver 1.1.0. We have included fixes that allows
more brokeness in the upstream DNS :) as well as several
notable new features:
* RFC7873 DNS Cookies
* RFC7858 DNS over TLS
* HTTP/2 web interface, RESTful API
* Metrics exported in Prometheus
* DNS firewall module
* Explicit CNAME target fetching in strict mode
* Query minimisation improvements
* Improved integration with systemd
You can read more about those features in our blogpost:
http://en.blog.nic.cz/2016/08/12/knot-dns-1-1-0/
Cheers,
--
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!
It seems I do have a problem with dnssec policy. DNSSEC for wisser.se is
automatically managed by knot. If you do a "dig dnskey wisser.se" you will
find a lot of old ZSK in my zone.
I did some "digging" with the keymgr tool and found the following conf for
all old keys
algorithm 8
size 2048
flags 256
active -1
retire 0
remove 0
I guess the retire and remove values are the problem. How do I set them for
the old keys? And how do I configure my policy to set them for future keys?
Kind regards
Ulrich
--
Ulrich Wisser
ulrich(a)wisser.se
Hello everyone.
I would like to provide some clarification on CVE-2016-6171 which has
been assigned to Knot DNS a few days ago. The CVE is basically about a
missing configuration option to limit the size of incoming AXFR. The
reporter claims that the master can generate infinite outgoing zone
transfer and thus exhaust the slave's resources.
We believe that master and slave servers should have appropriate trust
relationship. And therefore we think this problem rather fits
operational security that implementation security. If your master server
is trusted, then you should not be affected by this CVE.
Please note that the AXFR from untrusted master is not the only possibly
source of malicious zone transfer. The IXFR and DDNS qualify as well.
We have been requested to add a feature to limit incoming zone transfer
about a month ago [1]. The changes are almost finished and will cover
AXFR, IXFR, and DDNS. The feature will be included in Knot DNS 2.3 and
will be also backported for the older 1.6 release.
If you have any comments or questions, don't hesitate and tell us.
[1] https://gitlab.labs.nic.cz/labs/knot/issues/464
Best regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
tl;dr: I've searched the Internets a lot these past days, but weren't
able to find a way to make kdig and knsupdate work with keys. How is
this handled?
Hello knot people,
I've got a problem with kdig and knsupdate, specifically using the -k
parameter.
I'm using:
- Debian 8.5
- dnssec-tools 2.2-2 (out of stretch)
- knot-dnsutils 2.2.0-2~bpo80+1 (out of j-bp)
- dnsutils 1:9.9.5.dfsg-9+deb8u6 (out of jessie)
I'm creating the key with:
# dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com
which gives:
# cat Khost.example.com.+157+11483.*
host.example.com. IN KEY 512 3 157
42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I=
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: 42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I=
Bits: AAA=
Doing then:
# knsupdate -d -k Khost.example.com.+157+11483.
which gives:
;; ERROR: failed to parse keyfile 'Khost.example.com.+157+11483.'
;; DEBUG: srv_info_free: null parameter
I've found [1], and indeed, I'm running into the mentioned error if
using knot-dnsutils 1.6.0-1 out of jessie. Besides this, I wasn't able
to find anything useful.
But, doing this:
# knsupdate -y hmac-md5:host.example.com:42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I=
works, the same as nsupdate does:
# nsupdate -k Khost.example.com.+157+11483.
Could someone shed some light on what I'm doing wrong?
Any help appreciated...
Thanks in advance and for your work on knot!
All the best,
Georg
[1] https://lists.nic.cz/pipermail/knot-dns-users/2015-February/000579.html
Hello,
Even if I force wget to accept your expired certificate I
can't get apt-get update to work when pointing to your servers. It has
been like this for a few days now.
Hit http://ftp.debian.org wheezy-updates/main Translation-en/DiffIndex
Err http://deb.knot-dns.cz wheezy/main amd64 Packages
301 Moved Permanently [IP: 217.31.192.140 80]
Ign http://deb.knot-dns.cz wheezy/main Translation-en
W: Failed to fetch
http://deb.knot-dns.cz/knot/dists/wheezy/main/binary-amd64/Packages 301
Moved Permanently [IP: 217.31.192.140 80]
E: Some index files failed to download. They have been ignored, or old
ones used instead.
Could someone have a look at this please?
DO you think that many users have just switched back to bind because of
this? or is it just me?
Regards,
Maren.
Hi,
I anyway wrote a patch for disabling PMTUD for UDP socket
(for both IPv4/IPv6), and posted to issue tracker:
https://gitlab.labs.nic.cz/labs/knot/issues/467#note_24304
This patch includes extra bonus for mitigating DNS fragmentation attack
for IPv4 UDP, by using Linux's newer sockopt IP_PMTUDISC_OMIT.
I tried to illustrate how PMTUD badly interact with DNS over UDP,
which draft-andrews-dnsext-udp-fragmentation is addressing.
Assuming that there is a small MTU link between DNS requester
and DNS responder. Responder is serving large response,
which size is exceeding that small MTU (1454):
Apparently many DNS operator don't want timeout and retransmission.
MTU MTU MTU
Requester--1500--[router1]--1454--[router2]--1500-- Responder
| . . |
| . . |
o --------------------------------------------->| 1. Requester initiates
| . . | DNS query.
| . . |
| . .<-------------o 2. Responder generates
| . . | large DNS resnponse
| . . | (packet size > 1454)
| . . |
| . o------------->| 3. Intermediate router
| . . | drops large packet
| . . | due to small MTU, and
| . . | generates ICMPv6
| . . | "Packet Too Big",
| . . | since the response
| . . | packet can't go
| . . | through the link.
| . . |
| . . | Responder would learn
| . . | smaller path MTU toward
| . . | requester, but
| . . | does not resend
| . . | the response. (It's UDP!)
~ ~ ~ ~
| . . |
o---------------------------------------------->| 4. After timeout
| . . | requester retries
| . . | query.
| . . |
|<----------------------------------------------| 5. Responder generates
| . . | fragmented DNS response
| . . | which can go throgh
| . . | the "MTU 1454" link.
| . . |
Regards,
--
Daisuke Higashi