Is there any API description of the Varlink API, which you are referring to?
I have found:
- https://systemd.io/WRITING_RESOLVER_CLIENTS/
-
https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html
- https://systemd.io/USER_GROUP_API/
None of that mentions the raw mode you have mentioned, related to
hostname resolution.
On Do, 17.10.24 18:11, Petr Menšík (pemensik@xxxxxxxxxx) wrote:I certainly have answered the questions you raised for *myself*, though I am pretty sure you are not going to like my answer: I think the Varlink IPC APIs that systemd-resolved implements are the way to go. There's work going on to add ALPN and stuff hooked into systemd-resolved already. It provides simple SRV resolution APIs already, asynchronously. Lennart -- Lennart Poettering, BerlinThere is not anything wrong with Varlink IPC itself. There needs to be a decent encoding of every information shared back into the application. If DNS protocol should not be used for that, then there needs to be some other protocol to encode and decode that information. I want received information complex, at least (simple) possibility of it. That means the information transferred would not be simple anyway. It might need to be structured, possibly quite complex.As is HTTPS and SVCB record. Sure, SRV is relatively trivial in comparison. New records have arbitrary key-value parameters, which are future extensible.resolved offers you "cooked" and "raw" interfaces. If you opt for the "raw" interface you will get the data in DNS serialization (minus label compression and such), in the IPC replies.
Is this described somewhere? I haven't found it.
Does User/group
I think the problem is Varlink needs a new protocol for the name resolution. I have seen only DBus API for systemd-resolved. It is fine for some things, not working for others. But Varlink is the new API, which you say is not necessary anymore. Network BSD sockets are still handled by applications themselves, often made easier with some toolkits on top. If people still need socket handles, then they need something like struct sockaddr address for it. Ideally with a way to get additional information with it. Like TTL, servername, priority or weight.I cannot parse what you are writing here. Let me just say that D-Bus is problematic for doing DNS resolution with because DNS is really basic stuff that should work during earliest boot already. D-Bus is a late boot concept and in fact assumes that certain other OS functionality already works, such as user database resolution and logging services, both of which in turn might require host name resolution to already work. That makes D-Bus a poor choice as IPC for doing host name resolution. Varlink being much simpler and not requiring a broker always works, hence that's what we do.
Applications calling connect(2) call need struct sockaddr, obtained by getaddrinfo(3). They may use varlink to get that data, but still need some way to obtain that. That means some API to client applications.
But yes, we have realized we may need encrypted resolution already in Anaconda, which makes D-Bus activation quite early. Network Manager needs it. On the other hand, until you have working some network connectivity, the only data ready at that time can be provided by nss-files or nss-myhostname plugin. Other services do not have a way, how to fetch other usable information at that time. If they can use some plugins without specialized service, then that service needs to be up only when network is ready at least partially.
It depends. Of course handling timeouts and retransmissions is a pain. However, you can just rely on the service doing that. Except dnsmasq all other services should emit SERVFAIL, if it takes too long. The client should handle just simple pipe, stream or datagram, to a service. Ideally it should have simple way of obtaining minimal functionality provided from the service.I think we could still use unix domain socket in some standard path and send queries from applications to local daemons over it. DNS protocol is compressed enough and binary already. I am not sure if translating DNS message into varlink structures will make it actually simpler to parse. It would require completely new code on side of applications. I would use simplified DNS protocol on local pipe for IPC. That is close enough to what some applications already implemented or have libraries for. Though we need to pass AF_UNSPEC address request in single query, not like separate A+AAAA requests arriving to cache service.First of all, as mentioned "raw" RR lookups done via the Varlink IPC interface encode the RR data in DNS serialization. I think using the DNS protocol itself is highly problematic however, because the protocol is just so complex these days with multiple transports, and time-out/repeat behaviour that is just a complete mess when applied to local IPC.
Dunno. Varlink is a trivial IPC. In systemd-resolved we support it side-by-side with D-Bus. I have zero interest in adding a 3rd IPC interface, hence whatever you come up with, expect us to be very cool on the idea on adding more.
That sounds like Vendor Lock-in approach. Either you use our protocol or you are screwed. There are already multiple implementations doing DNS service. I think we need common interface for them to be interoperable, without forcing clients to support multiple interfaces for each. That is why I want to discuss it with wider audience. I can design my own API, but if it would be just one of many alternatives, it won't help. It would not improve overall experience, but just fragment implemented/able solutions.
I am looking for a generic interface, which could be served by multiple implementations. Even systemd-resolved. But at least DBus API does not make switching between different services simple. We have to mask systemd-resolved.service to be able to take its DBus name from dnsconfd. That is definitely not a best practice to recommend. Can you describe API, which can offer both systemd-resolved and also other service? Where the user can freely choose, which service suits him/her the best? To ensure client applications do not need modification or rebuild, when such service is changed?
The most important problem of existing system interface are blocking only calls. Every more complex program runs some kind of event loop, capable of handling multiple sockets and timeouts in a single thread. But that is not possible with API systems provide today. Modern programs are asynchronous for a good reason. I think providing them low-level building blocks still makes sense. They may be used inside higher level languages. I don't think DBus should be used, just because it has already existing integration to toolkits. It does not seem to be high-speed enough.D-Bus might not be great for "high-speed", but uh, it's still a a lot faster than a DNS lookup would require it. So, what can I say. There are good reasons to avoid D-Bus for this (see above), but "performance" really isn't it. Lennart -- Lennart Poettering, Berlin
DBus is common building blocks of GUI applications written in GTK
or Qt. But I haven't seen many server implementations with decent
DBus support. If you would like to observe busy (multi)gigabit
link with tcpdump, there might be a lot of queries coming, per
second. DNS itself is a quite efficient binary protocol, often
already implemented in clients relying on it. I trust you know
about D-Bus much more than me and that it can pass binary encoded
and structured information too. But I am not sure whether complete
name resolution history on machine should pass via DBus. In
whatever form.
The problem I see with DBus is that none of a good open source
dns servers have DBus interface implemented in it. Yet they are
done by masters of the DNS protocols, who often wrote RFC defining
how they should behave. Using DNS compatible messages would allow
to reuse their expertise. Translating DNS message responses to
Varlink interpretation might lose important information and create
not necessary translation layers. I think ideally each client
should be able to select, how complex information it understands
or wants. getaddrinfo(3) is a good thing for basic things, but
should be expanded and modernized a bit. For more detailed answers
something DNS-like should work.
-- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
