On Thu, 2022-08-18 at 16:39 +0000, Suraj Krishnan wrote:
> Hi all,
> 
> I wanted to revive this thread and provide an update on the status of this 
> feature/PR.
> 
> The feature adds a mechanism for privileged users to monitor DNS resolutions 
> on the system, by adding a new varlink interface that exposes a method for 
> clients to subscribe to such notifications. The feature will be off by 
> default. Lennart's suggestion to use varlink for this turned out to be quite 
> valuable and we've been successfully using this patch for the last few 
> months. We're using it to update the firewall (drop by default) based on 
> pre-configured allow-list of hostnames. We also leverage nftable's queue 
> feature to address race conditions associated with asynchronously updating 
> the network firewall.
> 
> I received great feedback from the community on the PR, much of which is 
> already incorporated. There are two more suggestions that aren't incorporated 
> yet:
> 1) Add "resolvectl monitor" functionality to provide a built-in way to 
> monitor the notifications and try out the feature easily (note that varlink 
> CLI tools are just as easy to setup/use)
> 2) Add a d-bus property when the feature is in use. This allows unprivileged 
> clients to be aware that DNS requests are monitored on the system.
> 
> At this point, I'm writing to gauge if the devs would be open to accepting 
> this patch in its current form, or would like to have 1) and/or 2) 
> incorporated into the same PR, or have any concerns about the feature in 
> general.
> https://github.com/systemd/systemd/pull/22845
> 
> Thanks
> Suraj

Yes the patch looks good, minus any eventual lingering bug fix needed,
if any. I'd say the D-Bus property is good to have immediately so that
we are careful about potential privacy implications. I don't think the
monitor command is needed for the first pass, if desired it can always
be added later.

> -----Original Message-----
> From: Lennart Poettering <lenn...@poettering.net> 
> Sent: Wednesday, February 16, 2022 9:53 AM
> To: Suraj Krishnan <sura...@microsoft.com>
> Cc: systemd-devel@lists.freedesktop.org; Andre Muezerie 
> <andre.mueze...@microsoft.com>
> Subject: [EXTERNAL] Re: [systemd-devel] [RFC] systemd-resolved: Send d-bus 
> signal after DNS resolution
> 
> [You don't often get email from lenn...@poettering.net. Learn why this is 
> important at http://aka.ms/LearnAboutSenderIdentification.]
> 
> On Di, 15.02.22 22:37, Suraj Krishnan (sura...@microsoft.com) wrote:
> 
> > Hello,
> > 
> > I'm reaching out to the community to gather feedback about a feature 
> > to broadcast a d-bus signal notification from systemd-resolved when a 
> > DNS query is completed. The message would contain information about 
> > the query and IP addresses received from the DNS server.
> 
> Broadcasting this on the system bus sounds like a bit too heavy. I am sure 
> there are setups which will resolve a *lot* of names in a very short time, 
> and you'd flood the bus with that. D-Bus is expressly not built for streaming 
> more than control data, but if you have a flood of DNS requests it becomes 
> substantially more than that.
> 
> Also, given that in 99.9%of all cases the broadcast messages would just be 
> dropped by the broker because nothig is listening this sounds needlessly 
> expensive.
> 
> What would make sense is adding a Varlink interface for this however. 
> resolved uses varlink anyway it could just build on that. Varlink has the 
> benefit that no broker is involved: if noone is listening we wouldn't do 
> anything and not have to pay for it. Moreover varlink has no issues with 
> streaming large amounts of data. And its easy to secure to ensure nobody 
> unprivileged will see this (simply by making the socket have a restrictive 
> access mode).
> 
> So yes, i think adding the concept makes a ton of sense. But not via D-Bus, 
> but via Varlink. Would love to review/merge a patch that adds that and then 
> exposes this via "resolvectl monitor" or so.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to