Re: Better control over what mDNS announces

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> Both of these (but especially the first) violate (one of) the
> point(s) of mdns - finding services without explicit network
> configuration.
Probably yes. But the current behaviour (for me) violates the point of a 
working printing ystem _with_ explicit network configuration.
It appears to be one of these "make it Just Work at home" features that make 
it fail in a larger-scale office environment.


> Unless you (ipf,pf,npf)-filter them unoperational - those should
> work, as they're (well, should be) only announced on the local link
> where the connection will work.
No, because CUPS isn't configured to listen on IPv6.

> However, if you want that as an _option_, ok with me.
Yes, sure, I'm speaking of options.

> when the idea of more than one address for a machine was new and exotic.
In my environment, more than one address _on one interface_ is indeed a 
special case (roving aliases for things like gateway/resolver you can't 
sensibliy announce vis DNS).

> They're not distinguished as well as you might think even on IPv4
Yes, I know. Stil I keep the notion of a main and alias addresses in my setup.

> I think more useful would be to have options to only announce or ignore 
> a specific set of addresses. Will also help for the former case.
I thought of that. But it may be difficult to express in the config.

> (To a certain degree your perceived problem seems to come from cups
> not exercising control over what addresses it uses and which it 
> wants announced? That is, less than optimal integration of mdns into
> cups?)
For PPD downloading, the server providing the CUPS service used to announce 
cups-ea.math.uni-bonn.de and my DNS provided a client with an address in the 
client's net that CUPS was known to listen on.
Now (in the Beautiful World of Bonjour) CUPS announces elbe.local and the 
client gets offered a bunch of addresses for elbe.local by mDNS.
Now we ran into two obscure problems: First, during our tests on a 
development server, CUPS announced trave.local and mDNS responded with 
(relative, IPv4) address .30, which worked. Then we moved to a production 
server which happened to also be one of our resolvers. So mDNS announced 
.20 (the basic address) plus .3, which is a roving alias for DNS resolution 
and CUPS is not configured to listen on .3.
Second, the machine has IPv6 support in the kernel, thus link-local addresses, 
but is not really set up to use IPv6 at this time. But mDNS announced the LL 
v6 address and then loading the PPDs failed. I want to be in control of 
whether we provide CUPS (or NFS or the Icinga Classic UI or whatever) over 
IPv4 or IPv6 for a set of clients. I don't want Bonjour to take over.