Re: Summary of the LLMNR Last Call

Ned Freed <> Tue, 20 September 2005 18:59 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EHnLB-0003F9-Ql; Tue, 20 Sep 2005 14:59:41 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EHnL9-0003F1-AL for; Tue, 20 Sep 2005 14:59:39 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id OAA22702 for <>; Tue, 20 Sep 2005 14:59:37 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1EHnQx-0006fB-DZ for; Tue, 20 Sep 2005 15:05:40 -0400
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for; Tue, 20 Sep 2005 11:59:21 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp;; s=mauve; t=1127242760; h=Date: From:Subject:MIME-version:Content-type; b=pWaAzgn9N6+/9VJrA4bPD9p+W 6RDbFPEnSrhoCxCD5sjMJwBkG416bwxuymx3000cfdP5WRF13wHeTOWX+pM6w==
Received: from by (PMDF V6.1-1 #35243) id <>; Tue, 20 Sep 2005 11:59:16 -0700 (PDT)
To: Russ Allbery <>
Message-id: <>
Date: Tue, 20 Sep 2005 11:53:06 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Mon, 19 Sep 2005 22:01:39 -0700" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <> <p0620074fbf5509dd070a@[]> <> <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Margaret Wasserman <>,, Bernard Aboba <>
Subject: Re: Summary of the LLMNR Last Call
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> Bernard Aboba <> writes:

> > b. Confusion between security issues and namespace separation.  In
> > peer-to-peer name resolution protocols, it is possible for a responder
> > to demonstrate ownership of a name, via mechanisms such as DNSSEC.  It
> > is also possible for a responder to demonstrate membership in a trusted
> > group, such as via TSIG or IPsec.  If DNSSEC is available, spoofing
> > attacks are not possible, and querying for FQDNs does not expose the
> > sender to additional vulnerabilities.  Both the mDNS and LLMNR
> > specifications agree on this point.

> We agree that home burglary is a serious problem.  This is why we
> recommend that everyone hire an armed guard for their house.  If your
> house is monitored by armed guards, burglary is very unlikely.  Given that
> there is an effective security mechanism available, there's really no need
> to consider simple deterrants that won't provide true security.

We do have a strong tendency to let the best be the enemy pf the good, don't

> > c. Lack of consideration of existing practice.  Internet hosts have used
> > multiple name resolution mechanisms based on a single API for more than
> > two decades, with no ill effects.

> "No ill effects" is a horribly inaccurate description of the effects of
> that design.  A much more accurate description would be that Internet
> hosts have used multiple name resolution mechanisms through a single API
> out of necessity for more than two decades, have suffered frequent ill
> effects up to and including major outages because of it, but have
> struggled along with that design because there are some features provided
> by it that are too useful to completely dismiss in general.  That being
> said, most systems attempt to avoid using those features when feasible and
> attempt to make all sources of information match exactly to avoid the
> serious and often hard-to-diagnose problems of conflicting information.

> If you think that using /etc/hosts, NIS, and DNS at the same time on
> systems to provide name resolution is a *success* story, your perceptions
> of the practical problems of name resolution in Internet hosts is
> drastically different than mine.  You've also had to maintain far less
> code to try to work around bizarre inconsistencies in gethostbyname
> responses than I have.

I could not agree more. This particular hairball has been a consisent source of
support problems around two decades now. In fact it may have set some sort of
record: I cannot think of anything else we were using 20 years ago is still
causing exactly the same sorts of problems it caused back then.


Ietf mailing list