knot-dns-users July 2016

knot-dns-users@lists.nic.cz

7 participants
5 discussions

forcing minimal fragment size for IPv6 datagrams

by Jan Včelák

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

6 years, 9 months

AXFR size limit (CVE-2016-6171)

by Jan Včelák

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.cz https://www.nic.cz

8 years, 2 months

kdig / knsupdate: "; ; ERROR: failed to parse keyfile '...' ; ; DEBUG: srv_info_free: null parameter"

by georg＠riseup.net

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

8 years, 2 months

Knot Debian installation - 301 Moved Permanently [IP: 217.31.192.140 80],

by Maren S. Leizaola

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.

8 years, 2 months

Re: [knot-dns-users] forcing minimal fragment size for IPv6 datagrams

by Daisuke HIGASHI

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

8 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users July 2016