Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Peter
@petzah
I've just installed knot-resolver from strech debian repo and noticed that by default tls port is bound to all interfaces(ListenStream=853). Shouldn't it be only for localhost?
Peter
@petzah
Another issue I have is systemd socket enabled thingy. In ansible, I want to configure kresd to listen on different port, so I will create the drop-in for kresd.socket and execute daemon-reload, now I want to systemctl restart kresd.socket to get it to different port but I get: "kresd.socket: Socket service kresd.service already active, refusing."
Peter
@petzah
Solution for me was to put BindsTo= for all 3 sockets into the kresd.service drop-in ref: https://lists.freedesktop.org/archives/systemd-devel/2015-February/027988.html
Andreas Rammhold
@andir
@petzah you need to clear out the variable in your drop-in file first. Using a "Variable=" line (not sure what the variables are) I did that in my puppet configuration since I wanted it to bind to different addresses
Peter
@petzah
@andir Thanks, it works! :)
Peter
@petzah
@andir and it doesn't :D .. next step would be to do some configuration in /etc/knot-resolver/kresd.conf and restart the daemon. Assumption is that because of service is socket activated then if I will bring down any of the systemd sockets the service should go down too, but it isn't. If one will stop kresd.socket, the service will bound to the interface instead of systemd (netstat -natp is kresd instead of init) which means it's not socket-activated anymore. Trying to bring up kresd.socket back up is yielding the message above (kresd.socket: Socket service kresd.service already active, refusing). By configuring tight dependency between sockets and service (e.g. with BindsTo=) this is not happening. Or my assumption is incorrect and I'm doing something wrong :D
Vladimír Čunát
@vcunat
I think listening on all interfaces on 853 wasn't intended. @oerdnj
Andreas Rammhold
@andir
@petzah i guess you figured it out by now but this is how I do it: https://gist.github.com/andir/d2c33f931d39894fd4a49a8a0efe0d00
Peter
@petzah
@andir Yes, but even with such config there is an issue with restarting daemon. (systemctl restart kresd.service won't work due to "unit kresd.service may be requested by dependency only" and systemctl restart kresd.socket won't work either because once it is stopped kresd daemon will bind to the interfaces insted of systemd)
try this:
Andreas Rammhold
@andir
i usually stop kresd.service after reloading the daemon, config changes to kresd will be picked up due to it being restarted on the next request
Peter
@petzah
  1. nc -v localhost 53
  2. systemctl restart kresd.socket
first is to activate daemon , second will try to stop and start kresd.socket
when socket is down, kresd will bound to the interfaces (verify with netstat -natp |grep 53)
Andreas Rammhold
@andir
i never stop the socket
Peter
@petzah
I see
Andreas Rammhold
@andir
and if I do I turn kresd off before, withdraw anycast annoucements etc..
Peter
@petzah
so for configuration (e.g. adding new options to kresd.conf) you just do systemctl stop kresd.service
Andreas Rammhold
@andir
yes
so (at least I think) no request will be lost but the service restarted
Peter
@petzah
ok, well this will confuse a lot of people
thanks for help :)
Andreas Rammhold
@andir
yw, I saw your ansible repo.. I'll probably give it a try on my private infrastructure :-)
Peter
@petzah
sure, it's not complete and approach is somehow different, also templates have a lot of duplicate code .. but it works for me right now :) fork and enjoy :)
Michal Cichra
@mikz
Hi! I'm working on API Gateway project in OpenResty and recently started focusing on our DNS resolving. Knot Resolver looks great so I was investigating how to use it from OpenResty via FFI.
Have someone else experimented with using it via FFI from OpenResty ? OpenResty is quite sensitive to blocking the event loop.
Michal Cichra
@mikz
But checking the API documentation (http://knot-resolver.readthedocs.io/en/latest/lib.html#apis-in-lua) I feel like that might not be the right approach for OpenResty as that API is really low level and I'm not sure if it would fit the OpenResty pseudo synchronous blocking on io model.
And a different but related question. Would kresd perform query de-duplication when entry is not in the cache? If there are two queries that arrive at the same time, how many queries to the upstream nameservers it is going to perform?
Vladimír Čunát
@vcunat
The kresd process needs to be in control of its (own) event loop. (Though I don't get what exactly you had in mind.)
Petr Špaček
@pspacek
I guess that these APIs are too low-level for you. The good news is that nothing is set in stone and if you can formulate the requirements someone might advise you where to pull strings inside kresd to get the intended result :-)
Michal Cichra
@mikz
I though that I could use the library to perform the DNS resolution over FFI instead of using DNS protocol :) So I'd not have to have the daemon running. But that would be just bonus points :)
Vladimír Čunát
@vcunat
Deduplication is done, but only within each process.
Michal Cichra
@mikz
Awesome. And checked documentation, but can't see it mentioned there so it is probably not supported. Can kresd listen on unix domain socket?
Vladimír Čunát
@vcunat
So if you run multiple processes and send an uncached query to them at once, it won't be OK.
The TTY for control is open either interactively or a named unix socket is created.
But I guess you meant listening for standard DNS queries :-)
Michal Cichra
@mikz
Yeah, that is acceptable. This would be running alongside the API Gateway in a Docker container, so just one process should be enough.
Yep. Listening for queries.
Vladimír Čunát
@vcunat
I think there's no explicit support for that.
Michal Cichra
@mikz
OpenResty cosockets support UDP over unix domain sockets so I was hoping it would be a bit more efficient when running in the same container.
Petr Špaček
@pspacek
... I would start optimizing later, when is actually works :-)
Vladimír Čunát
@vcunat
I would personally expect bottlenecks to be elsewhere.
Some reported performance degradation when running kresd within docker.
CZ-NIC/knot-resolver#28
Michal Cichra
@mikz
Thanks for the info. Will post some report when I do benchmarks comparing to dnsmasq. I expect the de-duplication could help a lot for my use case.
Vladimír Čunát
@vcunat
Looking forward to that :-)
Michal Cichra
@mikz
Morning. Any recommendation how to use knot-resolver on CentOS/RHEL ? I can see just Fedora packages. Checked EPEL, but it is not there either.
Vladimír Čunát
@vcunat
There might be even some basic dependencies missing or not in high enough version, e.g. we require libknot >= 2.3.1 and libuv >= 1.0.
I don't know if there's a better way than to build from source, unless you already use e.g. https://nixos.org/nix
Michal Cichra
@mikz
vcunat: yeah, some are not there at all like lua-sec-compat. I guess there is no plan to build also for CentOS right?