We have an agreement here. Passing complete resolution on general purpose broker like DBus is not a good idea. Having a separate socket is a better idea. I just think it does not have to implement generic IPC protocol, if we want it used for name resolution only. Which has already lightweight DNS protocol, which can be reused.On Mo, 21.10.24 12:38, Petr Menšík (pemensik@xxxxxxxxxx) wrote:Okay. It might be better than D-Bus, but having to make separate connections for every single resolution is still a bit wasteful.Uh. I mean, if you want, kep the connections around aftre each resolution and reuse them. But frankly, you are focussing on the wrong things. Roundtrips are wasteful, and D-Bus is rife of them. A singular bottleneck that the broker is is wasteful. But local AF_UNIX sockets are not in comparison, not even remotely.
If we can keep some context between two resolutions, just a single stream connection would be enough. If raw stream/TCP DNS is used, it can deliver random ordered responses over single connection. That seems even better option. Just use an unix socket for raw DNS. Of course additional resolution via Varlink would be still possible, but I would not propose them as a primary way.Sure, reinvent IPC another time. Have fun!
Already said. I do not want to reinvent general purpose IPC. Although we have examples in bind9, unbound and countless of other server software, that specialized sockets for runtime configuration and monitoring are used.
I would propose something like /run/resolver.socket, which primary system cache would listen on. It would use the same protocol as we have on 127.0.0.53, port 53. Just unix domain socket and few advantages of it.
Reconfiguration can be done via DBus or Varlink, why not. But not common resolution queries.
I never pretended systemd-resolved does not exist. It does. I just don't think it is the best implementation we could find. It has many advantages, but not only them.I know you don't like systemd-resolved, but maybe you can at least acknowledge that is does exist.
Thank you!Good luck with yet another C API.
Most of DNS RRsets are tiny. DNS can contain OPENPGPKEY records, which are not so tiny. It can contain also DNSKEYs. Especially those of a post quantum cryptography are rather large. Not something today's application is unable to process, but not tiny. Large DNS responses might be up to 64 kB, but sure, most of them are smaller than 1.2 kB.But mandatory base64 encoding and decoding can be avoided. If it can be avoided, then I think it should be.Sorry, but marhsalling is not where the cost is for local IPC. In current Linux systems it's roundtrips, roundtrips, roundtrips. Forget everything else. Lennart -- Lennart Poettering, Berlin
Marshalling is not free, but you are correct it is not a primary blocker. It depends what you mean by roundtrips. For example traffic monitoring tools like iptraf or tcpdump are likely to resolve often the same address.
I think in-application context would allow small cache inside the application. That would allow reusing recent response and do not bombard local cache service with repeated queries. But at the same time it needs to get information, how long it is allowed to cache records. It may set upper limit to TTL received, for example keeping a record max for 10s. Even if response contained 1 day. The rest would keep the cache service, which we can flush when needed.
But current APIs do not offer keeping context between
resolutions. Nor expose TTL of received answer.
At least we have agreement it needs a separate socket service. Not so much what to use on such socket.
I would like to avoid information lost in translation. The less
translation we need to make, the better for result correctness.
-- Petr Menšík Software Engineer, RHEL Red Hat, https://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
