Subject: RE: comments on mnds-00

From: [email-masked]
Date: Tue, 10 Apr 2001 12:20:33 +0300

Hi Levon, Erik, All,

See my response to one point of discussion below.

<snip>
> > I suggest that, just as other zeroconf protocols, a host may either
> > run this zeroconf protocol service or not.  This need not 
> be something
> > that can be turned off by DHCP, nor should it be - any more 
> than v4LL
> > autoconfiguration.
> 
> I don't agree. There must be a way to disable mDNS through DHCP, to
> prevent mDNS traffic in well managed (i.e. non-zero-conf) corporate
> environments, where the last thing users need is more network traffic.
> 
> > >It is not expected that a device "host.example.com." will 
> be manually
> > >configured to have additional name 
> > "host.example.com.local.arpa." when
> > >it is configured to use multicast DNS. Instead, a responder 
> > with a name
> > >"host.example.com." configured with ".local.arpa." suffix in 
> > its domain
> > >search configuration is authoritative for the name
> > >"host.example.com.local.arpa.". I.e. when responder with the name
> > >"host.example.com." receives an A type query for the name
> > >"host.example.com.local.arpa." it authoritatively responds 
> > to the query.
> > 
> > Why attache the suffix '.local.arpa' stuff?  Why not just multicast
> > a request for 'host.example.com'?
> 
> As I mentioned above, I don't see any problems with sending multicast
> queries for the names that don't end with ".local.arpa".
> 
I think that, if hosts may respond to a query for any name, so also those
not ending with .local.arpa, there should be a specified way to turn off the
mDNS behavior. As Levon mentioned, in managed networks it would be
undesirable to have nodes sending mDNS queries for any name e.g. as last
resort for resolving a host name.

I am not against responding to queries for any name, but it may complicate
things in case of a zeroconf-to-non-zeroconf transition takes place. If I am
using a non-FQDN initially in the zeroconf network, then after the
transistion the DNS will return an error/not resolve queries positively, if
mDNS was turned off by a DHCP server in the non-zeroconf network that the
zeroconf network just connected to. I'd then like to see that a responder
may respond to *any* name ending with .local.arpa (or other, nicer
suffixes), *and* to any FQDN that I may use in non-zeroconf environments as
well (so that name is also registered on soem DNS server).
Alternatively, my smart (m)DNS resolver could try, after faliure to resolve
a FQDN (no DNS server present) try to resolve  FQDN.local.arpa
automatically, without me having to type in the prefix.

Regards,
Sander

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 12 Apr 2001 08:42:31 -0700

> queries for the names that don't end with ".local.arpa".

I think that the original concern was that you'd end up sending
unnecessary queries for hosts that are not on the local link as a result
of moving through the searchlist.

>mDNS behavior.

The DHCP searchlist option accomplishes this. Hosts that are configured
without
.local.arpa in their searchlist neither send nor respond to mDNS queries.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Apr 2001 11:54:11 +0200 (MET DST)

Sander, Levon,

---

erik> I suggest that, just as other zeroconf protocols, a host may 
erik> either run this zeroconf protocol service or not.  This need 
erik> not be something that can be turned off by DHCP, nor should 
erik>  it be - any more than v4LL autoconfiguration.

levon> I don't agree. There must be a way to disable mDNS through 
levon> DHCP, to prevent mDNS traffic in well managed (i.e. non-zero-
levon> conf) corporate environments, where the last thing users need 
levon> is more network traffic.

As I argued in my other response, I argue that link-local scoped
mDNS traffic is not an issue.  Even on an enormous bridged network
with many hosts, there would not be enough mdns traffic to have
an impact on even a 1MB link.

---

mdns-00> It is not expected that a device "host.example.com." will 
mdns-00> be manually configured to have additional name 
mdns-00> "host.example.com.local.arpa." when it is configured to use 
mdns-00> multicast DNS.  Instead, a responder with a name 
mdns-00> "host.example.com." configured with ".local.arpa." suffix in 
mdns-00> its domain search configuration is authoritative for the name 
mdns-00> "host.example.com.local.arpa.". I.e. when responder with the 
mdns-00> name "host.example.com." receives an A type query for the 
mdns-00> name "host.example.com.local.arpa." it authoritatively 
mdns-00> responds to the query.
 
erik> Why attach the suffix '.local.arpa' stuff?  Why not just 
erik> multicast a request for 'host.example.com'?

levon> As I mentioned above, I don't see any problems with sending 
levon> multicast queries for the names that don't end with 
levon> ".local.arpa".

sander> I think that, if hosts may respond to a query for any name,  
sander> so also those not ending with .local.arpa, there should be 
sander> a specified way to turn off the mDNS behavior. As Levon 
sander> mentioned, in managed networks it would be undesirable to 
sander> have nodes sending mDNS queries for any name e.g. as last
sander> resort for resolving a host name.

If this is desirable, we have to define a new DHCP option to do it,
instead of overloading the name search list semantics.

---

sander> I am not against responding to queries for any name, but it 
sander> may complicate things in case of a zeroconf-to-non-zeroconf 
sander> transition takes place. 

In the case of name resolution, the way this transition takes place 
is the resolver is reconfigured to send unicast requests to a DNS
server.  The only way that a resolver will resort to using mDNS is 
if there is no DNS server available.  (How does this reconfiguration
take place?  I am taking this up in another thread.)

If mDNS is disabled, this is equivalent to saying that in the case
where there is no DNS server available hosts (without a static
configured host file mechanism) will be guaranteed to fail to 
resolve names.  Please discuss why this is a good thing that some 
administrators would want.

Regards,

Erik