Fwd: Re: Server issues

Scott Kitterman ubuntu at kitterman.com
Wed Nov 21 02:37:10 UTC 2007

On Tuesday 20 November 2007 20:46, Sebastien Estienne wrote:
> On Nov 21, 2007 1:48 AM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > On Tuesday 20 November 2007 17:18, Neal McBurnett wrote:
> > > I haven't really caught up over the last 18 months with what has
> > > happened in the big IETF debates about mDNS (so-called "Apple") vs
> > > LLMNR (Link-local Multicast Name Resolution - so called "Microsoft").
> > >
> > > But I haven't heard that there is anything on the road to
> > > standardization.
> > >
> > > RFC 4795 was published http://tools.ietf.org/html/rfc4795
> > >  Link-Local Multicast Name Resolution (LLMNR)
> > >
> > > but that is just an "Informational" RFC, and just about anyone who is
> > > persistent enough can get one of those published.
> > >
> > > Security issues have been identified with both of them,
> > > since they let systems mess with names that look like
> > > official dns names.
> > >
> > > I find a lot of appeal to finding a good standard for simplified
> > > configuration, like zeroconf.  But I think that it is a difficult
> > > thing to get right :-(
> >
> > The IESG note covers it pretty well (at least at a high level):
> >
> > IESG Note
> >
> >
> >    This document was originally intended for advancement as a Proposed
> >    Standard, but the IETF did not achieve consensus on the approach.
> >    The document has had significant review and input.  At time of
> >    publication, early versions were implemented and deployed.
> >
> > The lack of consensus (anyone can search the IETF main list for the last
> > call discussion on this RFC, it was pretty extensive) was primarily over
> > whether to use the mDNS or LLMNR protocols in the .local namespace. 
> > Informational or not, it's a published RFC.  The distinction among
> > Informational, Experimental, and Proposed Standard is significant within
> > the IETF community, but in the wider internet world, I don't think people
> > really know or care.
> So neither is a standard, so zeroconf is not more or less 'breaking'
> things than ms llmnr when using .local
> And it seems that ms recommends to use .local even for unicast dns,
> and thats neither a good practice.

Yes and equally the Standards for email are RFC 821/822 and not RFC 2821/2822, 
but try to operate a mail server without using the not the standards RFC.  As 
I said, for most, standard == has an RFC.  From an IETF point you are exactly 
right, but most won't know or care.

> > So currently we install and enable a system using an unstandarized
> > protocol that works in the same namespace with another protocol that
> > fulfills essentially the same purpose and that protocol is at least
> > documented in an (Informational) RFC.  The key point here is that the
> > IETF picked one and it isn't the one we use.
> First i don't see that ietf choosed one or the other, but the real question
> is: How many linux applications implement zeroconf, and how many implement
> llmnr?

No.  That's not the real question IMO.  The real questions are on the network.  
What are the interoperability considerations in a mixed LLMNR/mDNS network?  
What is the effect on the DNS root servers of the .local lookups bouncing off 
of them (I've looked and every SOHO router I've tested will just ask up the 
line for what any .local name should resolve to).

> > Personally, I don't like zeroconf a bit.  I like to actually configure my
> > boxes before they start to talk to other boxes.
> So you don't need it, that's why you can disable it.
> Zeroconf is not only about setting your ip adress automatically, it's
> about making your network printer just work without having to look for
> an IP/PORT, it's about sharing music without asking an IP adress.

Yes, so fix the architectural brokeness, don't run it by default and then lets 

> I totally agree that these technologies are only usefull in small
> local network (family or small business), and should/could be disable
> on servers that live in datacenters.

Put differently, it's suitable for servers not operating directly on the 

> And that's why it's hard to have a default install for servers.
> My home ubuntu server it totally different from the ubuntu servers i
> run in datacenter:
> - at home one server does everything from printing, dns, dhcp, lamp
> - in the datacenter each farm of servers only do one task: apache,
> mysql, storage, etc

Yes.  So I think that's a strong argument for why it should be removed.

> that's why in the datacenter i'm using something closer to
> ubuntu-minimal than the ubuntu-server CD.

I think (particulalry now that we have more tasksel options) the default 
vanilla Ubuntu Server install should be minimalistic.  None of my servers 
have avahi on them, but I think it's better to have it at least not running 
and I see little point in installing it if it's not going to run.

> And that's maybe what this thread is all about:
> Having a really minimalist working install for experienced users,
> personnaly i'm using FAI for my servers, it installs ubuntu-minimal +
> kernel + the specific packages for the task, eg: mysql-server.

I'd say the core ubuntu-server install should be that minimalist install and 
then less experienced users use tasksel to get what else they need.

> that's why i've never seen avahi on one of the servers i run in
> datacenters.

Me neither.

> > Additionally, they are both, IMO broken by design.
> How could we fix zeroconf?

The biggest issue (at least from my perspective) is the basic issue that if 
you issue DNS requests to a non-mDNS aware DNS server you end up dumping 
stuff onto the root DNS servers.  So there needs to be a way for discovery to 
occur without DNS requests.  

I guess my answer is change mDNS so it doesn't use DNS (moving it off port 53 
would be sufficient).

Scott K

More information about the ubuntu-server mailing list