Better control over what mDNS announces

[Edgar Fuß]

I'm used to having control over my DNS. If server X provides service Y for
clients in a certain net, the DNS view for these clients announces server
X's address that clients can reach.
With CUPS having abandoned its own browsing protocol (which worked perfectly
for our use case) I suddenly find myself in the Wonderful World of
Bonjour/Rendez-vous/Allez-hop and things automagically going wrong in
convoluted ways (like the client trying to contact the CUPS server on an
IPv6 interface that's not really operational or on an IPv4 alias that's
only used for DNS).
So I'm thinking about implementing some mdnsd/mDNSResponder options to
re-gain some control over what it announces. I haven't looked into how
feasable each option is; but I would like some comments, especially from
mDNS experts, if possible.

-- If the only IPv6 address on an interface is link local, regard that
interface as not set up vor IPv6 (and don't announce the LL address).

-- Don't announce link local addresses at all.

-- Don't announce any alias address, only the main one.

-- Ignore a given list of interfaces (or only serve a given list)

Comments, anyone?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@netbsd.org]

Post by Edgar Fuß
So I'm thinking about implementing some mdnsd/mDNSResponder options to
re-gain some control over what it announces. I haven't looked into how
feasable each option is; but I would like some comments, especially from
mDNS experts, if possible.
-- If the only IPv6 address on an interface is link local, regard that
interface as not set up vor IPv6 (and don't announce the LL address).
-- Don't announce link local addresses at all.

Both of these (but especially the first) violate (one of) the
point(s) of mdns - finding services without explicit network
configuration.

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.

However, if you want that as an _option_, ok with me.

Post by Edgar Fuß
-- Don't announce any alias address, only the main one.

My personal opinion: having a seperate notion of alias address is
a remnant from the old century when the idea of more than one address
for a machine was new and exotic. They're not distinguished as well
as you might think even on IPv4, and I think not at all on IPv6.
OTOH, IPv4 addresses can change their role from alias to "main" - I'm
not sure if back - implicitly.

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.

Post by Edgar Fuß
-- Ignore a given list of interfaces (or only serve a given list)

Sure.

(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?)

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by i***@netbsd.org
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.

Post by i***@netbsd.org
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.

Post by i***@netbsd.org
However, if you want that as an _option_, ok with me.

Yes, sure, I'm speaking of options.

Post by i***@netbsd.org
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).

Post by i***@netbsd.org
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.

Post by i***@netbsd.org
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.

Post by i***@netbsd.org
(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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@netbsd.org]

Post by Edgar Fuß

Post by i***@netbsd.org
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.

Maybe stupid question: wouldn't CUPS cooperate with the static DNS
method to enumerate services for Bonjour? If you can't find the
specs, I can look at my setup and summarize.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by i***@netbsd.org
Maybe stupid question: wouldn't CUPS cooperate with the static DNS
method to enumerate services for Bonjour?

Probably a mixture works. The only problem with the mDNS RRs that CUPS emits
is that the server name referenced to in the SRV record is foo.local, wich
then needs to be resolved by mDNS, an that's where I'm losing control.

So I added an option to CUPS to tell it what to put in the SRV RR instead.
That way, I can make it emit cups.math.uni-bonn.de, which resolves via
unicast DNS and I'm back in control.

See https://github.com/apple/cups/issues/5071.

(I also implemented mDNSResolver options to
-- only hand out the first non-LL address of an interface for each family
-- don't hand out LL addresses
-- ignore an interface/family combination with no routable address)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de