knot-dns-users

knot-dns-users@lists.nic.cz

4 participants
755 discussions

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.

9 let, 8 měsíců

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

9 let, 8 měsíců

glue and TC flag revisited

by Jan Včelák

Hello. There has been a rather long discussion about the change in TC flag setting for glue records after the Knot DNS 2.1.1 release. Based on the feedback, we have decided to tune the server's behavior a little bit. First of all, the definitions for "glue" differ and the recent RFC 7719 (DNS Terminology) doesn't help. So just to make this absolutely clear, let's define "mandatory glue": Mandatory glue are non-authoritative address records for the name servers in the delegation and within the bailiwick of that delegation. RFC 1034 Section 4.3.2 [1] describes the algorithm for response construction. As per step 3.b, we include mandatory glue into the additional section. If it doesn't fit, the TC flag is set. And as per step 6., we include other authoritative address records for name servers in the delegation. If these records don't fit, the TC flag is not set. [1] https://tools.ietf.org/html/rfc1034#section-4.3.2 Let's show that on an example. Consider the following zone: $ORIGIN tc.test. @ SOA ns admin 1 60 60 1800 60 ns AAAA 2001:DB8::1 foo NS ns.foo ns.foo AAAA 2001:DB8::10 bar NS bar NS a.ns.bar NS b.ns.bar NS ns.foo NS ns NS foo.test. bar AAAA 2001:DB8::20 a.ns.bar AAAA 2001:DB8::30 Now query for www.bar.tc.test would result in a response with delegation. The authority section would contain NS records for bar.tc.test. And the additional section will contain address records for following names as follows: - bar required (mandatory glue) - a.ns.bar required (mandatory glue) - ns optional (authoritative record, possibly with RRSIG) - b.ns.bar omitted (mandatory glue but unavailable) - ns.foo omitted (non-authoritative outside bailiwick) - foo.test omitted (non-authoritative outside zone) So what do you think? Is it better? This change is already included in the master branch (in case you want to test it). But there is still some time to change it before the next release. Best regards, Jan

9 let, 8 měsíců

receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED

by Roger Murray

Hello Everybody, I am seeing a response from a knot name server that I am working on that has me a little confused. When I do zone transfer requests from clients that aren’t allowed to do a zone transfer I expect to receive rcode 5 REFUSED, but I am receiving rcode 9 NOTAUTH. Is this the expected behaviour? Is this configurable? Best Regards, /rog knotd (Knot DNS), version 2.2.1 on Ubuntu 14.04 installed from .cz package knot: Installed: 2.2.1-1+trusty+1 Candidate: 2.2.1-1+trusty+1 Version table: *** 2.2.1-1+trusty+1 0 500 http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/ trusty/main amd64 Packages

9 let, 9 měsíců

should NSEC3 be default?

by Jan Včelák

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan

9 let, 9 měsíců

RRL and dnsproxy

by Matthijs Mekking

Hi, I recently started trying out Knot DNS and it has been a pleasure so far. I like the query modules and how easy it is to construct a query plan. I am thinking of putting knot as the public-facing server and enable RRl on it. However, I noticed that rate limiting comes *before* forwarding the unsatisfied query to the remote backend. This means effectively that all the queries will be rate limited by error classification. Wouldn't it be better to apply ratelimits after all stages of the query plan have been processed? In other words, rate limit based on the final response, rather than an intermediate state. This way you can truly use knot as a rate-limiting, public-facing server protecting your backend name server. Thoughts? Best regards, Matthijs

9 let, 9 měsíců

Knot DNS 2.2.1 patch release

by Jan Včelak

Hello everyone. CZ.NIC Labs has just released a patched version of Knot DNS. The 2.2.1 version contains some important bug fixes and a few small improvements. Let's jump directly into it: - The previous version was inconsistent in setting the TC flag for delegations with a glue. We have decided to modify the behavior slightly and the TC flag is now set always if a complete glue doesn't fit the response. - Logging of individual categories (server or zone) didn't work in the previous release. This problem is now resolved. Logging all categories (any configuration option) was not affected. - We have eliminated data race in the code responsible for zone file flushing. When more zone files were flushed concurrently, flushing of some zones could fail. This problem is fixed in the new release. - If you are running Knot DNS on OpenWRT, we advise you to update to the new release. There has been a critical bug possibly making the server to crash. - There had been several issues with the control utility: The timeout for reconfiguration is now parsed correctly. The "maxreaders limit reached" error is gone. And the interactive mode now completes multiple zone names if allowed by the command. The server will also refuse to perform the reload, if there is an active configuration transaction. - We have removed switch for Link Time Optimization from the configure script, because LTO is still rather problematic. If you want to use LTO, set the CFLAGS and LDFLAGS appropriately. - We have improved the logging and status messages to differentiate between an unavailable zone and a zone with zero serial. - We have added a list of PKCS #11 devices which had been tested with automatic DNSSEC signing. We are looking forward to your feedback. The sources are available as usual: Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.2.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz.asc Cheers, 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

9 let, 10 měsíců

Re: [knot-dns-users] Question about "views" and "RPZ"

by Marek Vavruša

Hey Jake, yes it does, RPZ is supported for views as is any other policy. There's an example of setting RPZ for a source-address subnet view in the documentation: http://knot-resolver.readthedocs.io/en/latest/modules.html#id3 Cheers, Marek > Does KnotDNS Resolver support the use of different RPZ's per-view? > > Looking to create a DNS setup that allows recursion to two separate > groups, one using one RPZ setup, the other using another. > > Is this possible with Knot? > > Thanks, > -jake > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >

9 let, 10 měsíců

Kernel Connection Multiplexor

by Robert Edmonds

Hi, Linux 4.6 was just released, and it includes a new feature called "Kernel Connection Multiplexor": http://kernelnewbies.org/Linux_4.6#head-d86a7a8affd7cefef85fff400e39403718b… 1.5. Kernel Connection Multiplexor, a facility for accelerating application layer protocols This release adds Kernel Connection Multiplexor (KCM), a facility that provides a message-based interface over TCP for accelerating application layer protocols. The motivation for this is based on the observation that although TCP is byte stream transport protocol with no concept of message boundaries, a common use case is to implement a framed application layer protocol running over TCP. Most TCP stacks offer byte stream API for applications, which places the burden of message delineation, message I/O operation atomicity, and load balancing in the application. With KCM an application can efficiently send and receive application protocol messages over TCP using a datagram interface. The kernel provides necessary assurances that messages are sent and received atomically. This relieves much of the burden applications have in mapping a message based protocol onto the TCP stream. KCM also make application layer messages a unit of work in the kernel for the purposes of steerng and scheduling, which in turn allows a simpler networking model in multithreaded applications. In order to delineate message in a TCP stream for receive in KCM, the kernel implements a message parser based on BPF, which parses application layer messages and returns a message length. Nearly all binary application protocols are parseable in this manner, so KCM should be applicable across a wide range of applications. DNS-over-TCP is definitely amenable to this scheme, since messages are framed with a 2-byte message length value. It also sounds like it can be combined with recvmmsg(): Q: What about the problem of a connections with very slow rate of incoming data? As a result your application can get storms of very short reads. And it actually happens a lot with connection from mobile devices and it is a problem for servers handling a lot of connections. A: The storm of short reads will occur regardless of whether KCM is used or not. KCM does have one advantage in this scenario though, it will only wake up the application when a full message has been received, not for each packet that makes up part of a bigger messages. If a bunch of small messages are received, the application can receive messages in batches using recvmmsg. Maybe this could help speed up a DNS server, or even improve resistance against slowloris style TCP attacks. -- Robert Edmonds edmonds(a)debian.org

9 let, 10 měsíců

Question about "views" and "RPZ"

by elsif

Does KnotDNS Resolver support the use of different RPZ's per-view? Looking to create a DNS setup that allows recursion to two separate groups, one using one RPZ setup, the other using another. Is this possible with Knot? Thanks, -jake

9 let, 10 měsíců

← Newer
1
...
47
48
49
50
51
52
53
...
76
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users