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,
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,
Hola,
As recently a variety of people claimed to me that 'running DNSSEC is
not scary'.... I was like, lets try again after having tried it ~10
years ago and it failing miserably.
DNSSEC auto-maintain style looks to be better; still not as nice as
running dual-nsd's in master mode; but we'll live with those moving parts.
It ran fine for a bit, till I noticed the signatures of the zone had
expired and noticed the master simply did not bother to update the sigs
anymore. So much for 'automatic' mode.
Restarting it caused a nice crash:
Debian provided jessie-backports 2.3.1-1~bpo8:
```
knotd[6679]: *** Error in `/usr/sbin/knotd': double free or corruption
(out): 0x00007f4244042e80 ***
```
Then was like... lets try the latest edition:
Debian provided unstable 2.3.2-1:
```
knotd[11892] general protection ip:7fb8f7f0f218 sp:7fb8ce1cc3b0 error:0
in libc-2.24.so[7fb8f7e98000+195000]
````
yes, that is on a newer libc, hence different style error message it seems.
The 2.3.1 edition was able to report:
```
error: [example.com] changes from journal applied 1 -> 1 (invalid parameter)
````
before crashing out, the 2.3.2 just borks out.
Unfortunately there are no dbgsym packages for those editions, thus
can't easily dig what goes wrong where without having to resort to
manually building it all.
I could also not find a way to signup to:
https://gitlab.labs.nic.cz/users/sign_in
to be able to file a ticket about this.
Any extra details that one should be providing outside of the above
(link to that list is welcome ;) )
Should I attempt knot-nightly?
Greets,
Jeroen
PS: News on https://labs.nic.cz/en/ ends in April 2016...
Dear Knot DNS users,
CZ.NIC is proud to release a new version of Knot DNS. This is mainly
bug fix release, but there are some small improvements included as
well.
There are few fixes related to timers and DNSSEC. We have also fixed
double free in journal code, and memory leak in kzonecheck. All domains
are now fully-qualified in the logs and there's a new utility to print
journal contents - kjournalprint.
We would also like to invite everyone to migrate from Knot DNS 1.6.x
to the current stable Knot DNS 2.x.x release.
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.3/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.3.3.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.3.3.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/
--------------------------------------------
