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...
Hi,
I am just about to create some SPF records for my domain, and it seems I can't
do it the right way.
The record should look like
preissler.co.uk. 3600 TXT "v=spf1 mx -all"
and I am creating it with knotc, interactive or not doesn't matter.
knotc zone-begin preissler.co.uk
knotc zone-unset preissler.co.uk preissler.co.uk. 3600 TXT "v=spf1 mx -all"
knotc zone-commit preissler.co.uk
this then gives me
[preissler.co.uk.] preissler.co.uk. 3600 TXT "v=spf1" "mx" "-all"
which is wrong.
If I use "'" it's the same. Then using
knotc zone-set preissler.co.uk preissler.co.uk. 3600 TXT v=spf1 mx -all
I get
error: (name does not belong to the zone) [preissler.co.uk] preissler.co.uk. 3600 TXT v=spf1 mx -all
I am aware I could just edit the zonefiles or use DDNS probably... but surely, there must be a way?
Regards
Thomas
--
www.preissler.co.uk | Twitter: @module0x90
GPG: BA359D78200264B363314AF5E3839138A11FFD2A
Dobry den,
pokousim se rozbehnout knot-2.3.1 (kompilace z ports) na jailu na FreeBSD 11
Problem je v tom, ze knot neodpovida na udp portu a to i kdyz to zkousim
primo v jailu.
Jine porty napr. smtp primo z jailu funguji, mozna je to jenom nejaka
chyba v nastaveni
knot-2.3.1
Toto vsechno jsem zkousel:
* netcat z jailu na stejny jail udp port 53 - funguje
* netcat z hostu do jailu udp 53 - funguje
* netcat z jineho hostu na host kde bezi jail udp 53 - funguje
Takto to dopadne primo z jailu ale i z jineho hosta:
# kdig liguros.net aaaa @ns1.liguros.net
;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP)
;; WARNING: response timeout for 5.135.156.9@53(UDP)
;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP)
;; WARNING: response timeout for 5.135.156.9@53(UDP)
;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP)
;; WARNING: response timeout for 5.135.156.9@53(UDP)
;; WARNING: failed to query server ns1.liguros.net@53(UDP)
Toto vidim v pfctl -s states
all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[60288]
NO_TRAFFIC:SINGLE
all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[40209]
NO_TRAFFIC:SINGLE
relevantni rules
pass in inet6 proto tcp from any to 2001:470:cadd:1::5 port = domain
flags S/SA keep state
pass in inet6 proto udp from any to 2001:470:cadd:1::5 port = domain
keep state
takto jsou jeste nastavene rdr na ip4 adresu jailu:
rdr pass on em0 inet proto tcp from any to any port = domain -> 10.0.0.5
rdr pass on em0 inet proto udp from any to any port = domain -> 10.0.0.5
rdr pass on lo1 inet proto tcp from any to any port = domain -> 10.0.0.5
rdr pass on lo1 inet proto udp from any to any port = domain -> 10.0.0.5
i kdyz nemyslim si, ze je to pf vina, protoze se do jailu napr. pomoci
netcat "dostanu"
ns jail:
ns:/usr/ports/dns/knot2@[22:44] # sockstat
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root knotd 1650 7 dgram -> /var/run/logpriv
root knotd 1650 8 udp4 10.0.0.5:53 *:*
root knotd 1650 9 tcp4 10.0.0.5:53 *:*
root knotd 1650 10 udp6 2001:470:cadd:1::5:53 *:*
root knotd 1650 11 tcp6 2001:470:cadd:1::5:53 *:*
root knotd 1650 15 stream /var/run/knot/knot.sock
Poradte mi prosim, jak danou vec dale debugovat.
Predem mockrat dekuji.
Pavol
###############################################
English follows
###############################################
I am trying to get knot 2.3.1 (from ports) working in a jail, but I am
unable to connect to the udp port even when trying directly from jail.
Using netcat from within jail and also from other machines gets through
into the jail. I don't think it is pf's fault.
How can I debug this a bit more?
Thank you for your help
Pavol
--
Email encryption for everyone via @fsf
https://u.fsf.org/zb
Thank you,
this (--enable-recvmmsg=no) fixes it for me. Hopefully the patch and new
version will get into ports soon.
Thank you very much for your help.
Pavol, now with working DNS on FreeBSD :)
On 24.11.2016 13:05, Leo Vandewoestijne wrote:
> On Thu, 24 Nov 2016, Vladim??r ??un??t wrote:
>
>> Hi,
>> I hope English will be understandable enough (to you).
>>
>> On 11/23/2016 11:00 PM, Pavol wrote:
>>> I am trying to get knot 2.3.1 (from ports) working in a jail, but I am
>>> unable to connect to the udp port even when trying directly from jail.
>>> Using netcat from within jail and also from other machines gets
>>> through into the jail. I don't think it is pf's fault.
>>>
>>> How can I debug this a bit more?
>>
>> Was knot compiled with recvmmsg support? The FreeBSD implementation of
>> this was buggy and I don't know which version got fixed:
>> https://github.com/freebsd/freebsd/pull/91
>> It's possible to disable the functions by passing --enable-recvmmsg=no
>> to ./configure.
>>
> I was already on that, and requested that two weeks ago:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214303
>
> Somehow my confirm did not came trough, I just did that again.
>
> --
>
> With kind regards,
>
>
> Leo Vandewoestijne
> <***(a)dns.company>
> <www.dns.company>
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>
--
Email encryption for everyone via @fsf
https://u.fsf.org/zb
I'm an engineer at Dyn and I work on the same team as Matthijs Mekking.
I noticed that commit 3f950e1d (
https://gitlab.labs.nic.cz/labs/knot/commit/3f950e1d3f323b0ebbd339de29f8c8b…)
changes the handling of the CD bit in responses. The test code comments
indicate that this is in accordance with
https://tools.ietf.org/html/rfc4035#section-3.1.6, but my reading is that
it contradicts section 3 of the same RFC. I was wondering if somebody
could explain the history or the thinking behind this change.
Thanks in advance!
John-Paul Gignac
Hi,
I am about to migrate my authoritative Bind instance to Knot.
My server is Debian Jessie, and the available packge there is 1.6.0-1.
I wanted to play on my Arch Linux installation at home to try the migration
out, so I am trying to compile aur/knot-lts, which is 1.6.8-1.
Compiling it is fine, but "make check" fails:
dnssec_sign.............FAILED 45, 50, 53, 56 (killed by signal 6, core dumped)
I tried 1.6.0 directly from source as well, same for 1.6.8 from source.
I even downloaded the Debian source and compiled that on AL, same error.
ldd tests/.libs/lt-dnssec_sign
linux-vdso.so.1 (0x00007ffc1a1d2000)
libknot.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/.libs/libknot.so.0 (0x00007fda7c3b4000)
liblmdb.so => /usr/lib/liblmdb.so (0x00007fda7c19f000)
libzscanner.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/zscanner/.libs/libzscanner.so.0 (0x00007fda7bf45000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fda7bd2f000)
libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007fda7bb29000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fda7b925000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fda7b708000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fda7b404000)
liburcu.so.4 => /usr/lib/liburcu.so.4 (0x00007fda7b1fc000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fda7ad84000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fda7a9e6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fda7c5db000)
liburcu-common.so.4 => /usr/lib/liburcu-common.so.4 (0x00007fda7a7e1000)
Versions:
usr/lib/liblmdb.so is owned by extra/lmdb 0.9.18-2
usr/lib/libz.so.1 is owned by core/zlib 1.2.8-4
usr/lib/libcap-ng.so.0 is owned by extra/libcap-ng 0.7.8-1
usr/lib/libdl.so.2 is owned by core/glibc 2.24-2
usr/lib/libpthread.so.0 is owned by core/glibc 2.24-2
usr/lib/libm.so.6 is owned by core/glibc 2.24-2
usr/lib/liburcu.so.4 is owned by community/liburcu 0.9.2-1
usr/lib/libcrypto.so.1.0.0 is owned by core/openssl 1.0.2.j-1
usr/lib/libc.so.6 is owned by core/glibc 2.24-2
usr/lib/liburcu-common.so.4 is owned by community/liburcu 0.9.2-1
I have attached the detailed segfault output separately.
Regards
Tom
--
www.preissler.co.uk | Twitter: @module0x90
GPG: BA359D78200264B363314AF5E3839138A11FFD2A
Hi,
I have recently started using Knot Resolver.
Thanks for that really nice piece of software.
Knot Resolver seems to cache the TTL of parent zone (= delegation) instead
of the TTL which is in the zone itself.
dig +noall +auth @n.ns.at univie.ac.at ns
univie.ac.at. 10800 IN NS ns3.univie.ac.at.
univie.ac.at. 10800 IN NS ns4.univie.ac.at.
univie.ac.at. 10800 IN NS ns5.univie.ac.at.
univie.ac.at. 10800 IN NS ns7.univie.ac.at.
univie.ac.at. 10800 IN NS ns8.univie.ac.at.
univie.ac.at. 10800 IN NS ns10.univie.ac.at.
dig +noall +ans @ns10.univie.ac.at univie.ac.at ns
univie.ac.at. 600 IN NS ns7.univie.ac.at.
univie.ac.at. 600 IN NS ns4.univie.ac.at.
univie.ac.at. 600 IN NS ns8.univie.ac.at.
univie.ac.at. 600 IN NS ns3.univie.ac.at.
univie.ac.at. 600 IN NS ns5.univie.ac.at.
univie.ac.at. 600 IN NS ns10.univie.ac.at.
dig +noall +ans @ns10.univie.ac.at ns10.univie.ac.at a
ns10.univie.ac.at. 600 IN A 192.76.243.2
Knot Resolver is caching 10800 instead of 600:
dig +noall +answer @127.0.0.1 ns10.univie.ac.at a
ns10.univie.ac.at. 10634 IN A 192.76.243.2
Bind, unbound and pdns-recursor cache authoritative TTL (600).
I have tried to file a bug report at
https://gitlab.labs.nic.cz/labs/knot/issues , but I wasn't able to create
a user account.
cheers,
-arsen
