[RFC] More flexible/extensible reflect-filters

[kiler129]

Background

There are two environments that I manage Avahi in: a large laboratory and my own house. Both suffer from mDNS pollution for different reasons. With 200 students with MacBooks and iPhones you can imagine how a list of available monitors looks like. In my home environment almost every device wants to advertise on mDNS creating quite of a mess.

Filtering mDNS

In both environments different devices are separated into separate VLANs. This necessitates Avahi in reflector mode. While Avahi offers reflect-filters, to my understanding it can only perform basic matching by e.g. a hostname and allow these to be propagated. However, it doesn't account for scenarios which could be very useful, especially with larger environments:

• Allow publishing of any service but only from a set of IPs
  • I realize that this can be spoofed
  • Allowing publication by a criterion of e.g. "if record contains target IP = 123" and "claims to come from IP 321" could solve this problem however
• Allow only subset of service types
  • e.g. only IPP being allowed on a printer VLAN, without _device-info._tcp
  • This is already sort-of possible, but applies globally to the whole reflector
• Allow filtering by property
  • For example, HomeKit/Matter devices put their MAC address in id field. Being able to only whitelist selected devices, regardless of their current name, would be very useful.
  • Being able to limit e.g. _airplay._tcp. advertisements to model=AppleTV* would solve a lot of issues in our lab.

Alternative solutions

• Some of these restrictions can be enforced with clever L2 ACLs. However, this is neither flexible nor scalable. In addition, often L2 ACLs are a very limited resource (as are executed on an ASIC) and using them to enforce mDNS rules doesn't feel right.
• I can of course roll-my-own solution that listens on mDNS advertisements on all VLANs and manages filtering, but since Avahi already contains robust reflector mode AND filtering support, I didn't prototype this solution.

Extending filtering

I looked at the current implementation of filtering and it's clean and simple. Adding more advanced filtering seems feasible, if a good structure is devised. Unfortunately, this comes with increased code complexity and maintenance burden, even if done properly.

Alternatively, which may be even a better idea, adding a hookable external service that is responsible for "voting" whether record should be included or not. That way, any rules can be implemented by an external process. This has an advantage of removing any responsibility from Avahi - it simply gets a premade decision. Since conveniently Avahi already uses DBUS, using a synchronous dbus-call-method with configurable timeout could be a good solution here, and shouldn't add much complexity to the Avahi code.

WDYT?

I created this issue to mostly discuss how maintainers of this project feel about the idea and its feasibility, not necessarily as "feature request".

[evverx]

Personally I'm not sure avahi should be in the business of enforcing any "policies". That feature seems to have been introduced to cover a niche use case and to judge from https://github.com/lathiat/avahi/issues/438 and https://github.com/lathiat/avahi/issues/297 it's just confusing. If it hadn't been released I'd personally just drop it.

[evverx]

This issue has been open for more than a year and there don't seem to be any thumb-ups, comments or anything like that. I think it can be closed.

Generally the avahi reflector has a bunch of bugs that need fixing before any new features can be even considered and people generally switch to other reflectors due to those bugs.