These are chat archives for CZ-NIC/knot-resolver

25th
Jun 2018
msehnout
@msehnout
Jun 25 2018 13:43
Do you have any code in the resolver where you parse output from the /run/knot-resolver/control socket? I could use some inspiration. I wrote some code to process the output, but it seems fragile to me with respect to termination conditions. It simply reads line by line until there is a line containing either new line only "\n" or a prompt with a new line "> \n". Is there a better way?
Vladimír Čunát
@vcunat
Jun 25 2018 13:45
There is an undocumented binary interface that we used for the kresc prototype.
Petr Špaček
@pspacek
Jun 25 2018 13:45
@msehnout First of all, what are you attempting to do?
msehnout
@msehnout
Jun 25 2018 13:45
@pspacek reconfigure knot-resolver during runtime
so far only policy rules
Vladimír Čunát
@vcunat
Jun 25 2018 13:47
So the point is to check for errors etc, I guess?
Petr Špaček
@pspacek
Jun 25 2018 13:48
I think best approach would be to send out a code which prints your own delimiter, i.e. do the policy magic + print/write whatever you need to the terminal to disambiguate the output.
msehnout
@msehnout
Jun 25 2018 13:48
@vcunat yes, but to read the output as well
In general I'd like to wrap the whole IPC into some simple API
Petr Špaček
@pspacek
Jun 25 2018 13:49
@msehnout Before you spend too much on this ... we have a project to develop YANG model for DNS resolvers and this will ultimatelly provide you with NETCONF/RESTCONF API.
Vladimír Čunát
@vcunat
Jun 25 2018 13:50
In any case, the binary output of strings in there is simple - first 4-byte length (unsigned, network byte order) and then the string of that length.
Petr Špaček
@pspacek
Jun 25 2018 13:51
I do not know your timelines etc. but it might make sense to contribute to the YANG project instead of wasting time on custom hack ... The "binary" protocol is just stopgap measure and will go away once we have the YANG pieces in place.
Vladimír Čunát
@vcunat
Jun 25 2018 13:52
Yeah, it's still experimental and may not be kept in future :-)
(the binary format)
msehnout
@msehnout
Jun 25 2018 13:55
ok in that case I won't invest any time into the binary protocol :)
Do you have any publicly available plans for the YANG model?
I was looking into the gitlab issues and haven't seen anything mentioning that.
Petr Špaček
@pspacek
Jun 25 2018 13:59
It is not in Knot Resolver's Gitlab because the aim is to have shared protocol among more vendors, i.e. single interface to rule them all (or at least some).
The project is in early stages but it can generate (limited limited!) configs for Knot Resolver and Unbound. Now we need to extend this with other configuration options etc.
msehnout
@msehnout
Jun 25 2018 14:08
So basically if this worked and I was using the NETCONF API only I could switch between Unbound and Knot Resolver without any changes to my application?
Petr Špaček
@pspacek
Jun 25 2018 14:09
Yes, assuming you do not use uniq features of any of these.
(YANG can support some vendor-specific extensions so the API might offer you stuff which is not supported elsewhere, for example.)
msehnout
@msehnout
Jun 25 2018 14:10
Sure, that makes sense.
Vladimír Čunát
@vcunat
Jun 25 2018 14:11
I think the plan is to support even (some) unique features - those will just be applied only in the respective backends and ignored in others.
(It's certainly possible to do it.)
msehnout
@msehnout
Jun 25 2018 14:12
Perfect :), this idea seems like a substantial simplification to what I wanted to implement by hand.
I will look into this project further, because I've never heard about YANG before, but it seems worth some effort.
Thanks!
Petr Špaček
@pspacek
Jun 25 2018 14:14
It came from lower layers of networking but it is generic enough for almost anything.
E.g. https://tools.ietf.org/html/rfc8343#appendix-A might give you an idea how the model looks. The API is generated from the model and then all what's missing are "hooks" for each implementation to transform the abstract description (data stored in the model) into paritcular configs, e.g. into policy statements for Knot Resolver.
This can (and should) be extended to work on live instances using their particular APIs. (i.e. Knot Resolver's socket or unbound-control)
Petr Špaček
@pspacek
Jun 25 2018 14:20
Keep in mind that this is experiment and is missing the "read" part, but we want to have it eventually.
msehnout
@msehnout
Jun 25 2018 14:24
Sure, thanks for the links I will look into it.
Petr Špaček
@pspacek
Jun 25 2018 14:24
You are welcome!
(Let us know if you get stuck, it might be a bit difficult to start from scratch.)