On Mo, 14.10.24 22:53, Petr Menšík (pemensik@xxxxxxxxxx) wrote:I think struct addrinfo used by getaddrinfo() is basically good output even for HTTPS record. But it needs in addition also key=value metadata with additional parameters. Similar for SRV. The end result is still ordered list of addresses. But we need a way to extract ALPN, ECH and other parameters. Do you have good recommendation, where to discuss this?I am not convinced that in 2024 it's really worth discussing a new C level API. The world is not purely C anymore, and various programming languages these days try to avoid just being libc wrappers. Moreover, the complex protocols involved should not be implemented in-process anymore, there should be process isolation in between. Hence, I am pretty sure you have to focus on some form of local IPC API between client and resolver.
There needs to be some common level, what information should be available from the system. Of course, designing generic to use API is not a simple task. Especially if it should be simple to use for beginners and still powerful enough even for more advanced programmers.
I agree that complex protocol should not be part of applications.
It is okay to have some service to use. Yes, with usage of any
encrypted DNS protocol complete implementation in end applications
does not make sense. It needs local service to share some state,
reduce number of TLS session initializations and such. But if they
need to get more complex information, simple protocol cannot
deliver it.
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, Berlin
There 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.
What I don't like about systemd-resolved is how poor service it provides on port domain. If it were working just like nscd daemon and cached only requests received via nss-resolve plugin, I would not oppose. But many details of how DNS is implemented in it are problematic (in my opinion) and are not the best practice example. Mixing of multiple protocol on localhost port 53 were a terrible idea from the start and does not work well.
I have visited about:networking#dns in my Firefox and were suprised. Cool, it has own cache with TTL values. Can other application like curl do that using getaddrinfo(3) call? Nope, it cannot. No TTLs are in those responses. Nor additional data. How it can access mdns names then, I ask myself? It needs to use own DNS protocol client implementation to get also TTL. It needs that also to fetch HTTPS RR and parse it now. What if I wanted to provide HTTPS RR over mDNS? Yes, I have seen such attempts reported on Avahi. Why not?
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 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.
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.
Cheers, Petr
-- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
