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
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
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
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
