Subject: [dns-dir] "Bonjour" protocol doc suite

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Sep 2010 13:06:42 +0200

The authors of the following documents have published revisions and
have asked me to bring them back to the IESG as AD sponsored
submissions:

Multicast DNS, <draft-cheshire-dnsext-multicastdns-11.txt>
DNS-Based Service Discovery, <draft-cheshire-dnsext-dns-sd-06.txt>
Requirements for a Protocol to Replace AppleTalk NBP,
   <draft-cheshire-dnsext-nbp-08.txt>

As many of you are likely aware, these documents have been reviewed by
the IESG, and the mDNS and DNS-SD docs have been through IETF last
call (as far as I can tell, the NBP doc has been reviewed by the IESG
but has not gone through an IETF last call).  The newly published
revisions of these documents take the previous reviews into account
and I believe they are close to ready for re-review by the IESG and
the IETF.

During the previous reviews of the mNDS and DNS-SD documents, the
question of "Standards Track" versus "Informational" was raised.  The
authors have addressed the specific comments from previous reviews
related to this question and have asked that the documents be
published as "Standards Track".

I know these are long documents, but I would like to get at least
preliminary feedback on the docments from the DNS Directorate before
putting them back on the IESG agenda.  If you know of any reason why I
should not go ahead with an IETF last call, please let me know by Thu,
Sep 16.  Any discussion of the docs and how to proceed with their
review would be welcome and appreciated.  A more thorough review can
be provided during the IETF last call.  If reviewers want to read the
last call comments for the mDNS and DNS-SD docs, the relevant threads
are available at:

http://www.ietf.org/mail-archive/web/ietf/current/msg59418.html
http://www.ietf.org/mail-archive/web/ietf/current/msg53588.html

respectively.

One important issue that will need to be resolved is the disposition
of ".local.", as used by mDNS.  This issue seems to be related to the
"sink.arpa." issue (I think I understand the differences between the
two issues), which has been black-holed by the IAB.  I will restart
the sink.arpa. discussion in anticipation of a similar discussion
about .local.

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Sep 2010 09:01:31 -0400

> of ".local.", as used by mDNS.

What is there to resolve? mDNS is deployed code that is used today. It
uses .local. That is reality. What can we do other than record that fact?

There is no need (IMO) to blow this up into an entire meta-discussion
about sink.arpa, etc.

A discussion about sink.arpa might be a fine thing, but I don't see
why the two need to be bundled together, unless the goal is simply to
delay everything.

Thomas

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Sep 2010 09:08:17 -0400

Oh, but think of the fun we could have pushing back on Stuart's
insistence that this is DNS (as opposed to a new protocol with
different semantics that reuses portions of DNS's syntax).

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Sep 2010 15:10:30 +0200

Just shoot me now.

Seriously, there was pushback from the IAB on the I-D requesting the registration of sink.arpa.  The authors responded, and the IAB hasn't responded.  I want to know if what's written in the mDNS doc about the use of authority over .local. makes sense, and how it relates to sink.arpa.

- Ralph

On Sep 13, 2010, at 3:08 PM 9/13/10, Rob Austein wrote:

> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 13 Sep 2010 10:15:43 -0400

There are two issues here:
	special names in DNS such as sink.arpa. and .local.
and	reuse of DNS format by other protocols i.e. LLMNR and Bonjor.

The first is emotional the second one is technical, but we have already 
crossed that bridge, there is no reason to hold up MDNS for that reason.

On the second issue .local IMHO is a good idea and the only reason 
people have had heartburn about it is that this crossed the boundary 
between IETF and ICANN. ICANN has in fact accepted that ".local" is in 
use and thus it is not available as TLD allocation. As far as I can tell 
ICANN would be happy to have documentation as to why .local is not to be 
allocated.

As to sink.arpa. it is global name, .local is supposed to be scope 
restricted, thus it may exist in certain contexts but not all, sink.arpa 
is not supposed to exist at all.

The second purpose of the sink.arpa document is to create a way for 
special purpose names to be allocated in IETF/IAB managed space rather 
than in the TLD space.

	Olafur

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Sep 2010 21:01:07 +0200

Olafur...

On Sep 13, 2010, at 4:15 PM, Olafur Gudmundsson <[email-masked]> wrote:

> The first is emotional the second one is
V 
> , but we have already crossed that bridge, there is no reason to hold up MDNS for that reason.

Did you mean "reuse of DNS" is emotional while the .local issue is technical?

> 
> On the second issue .local IMHO is a good idea and the only reason people have had heartburn about it is that this crossed the boundary between IETF and ICANN. ICANN has in fact accepted that ".local" is in use and thus it is not available as TLD allocation. As far as I can tell ICANN would be happy to have documentation as to why .local is not to be allocated.

Are you Ok with the documentation formulation in the mDMS doc?

> 
> As to sink.arpa. it is global name, .local is supposed to be scope restricted, thus it may exist in certain contexts but not all, sink.arpa is not supposed to exist at all.

Does the difference in scope affect how the two names are treated and documented?

> 
> The second purpose of the sink.arpa document is to create a way for special purpose names to be allocated in IETF/IAB managed space rather than in the TLD space.

Ok.

- Ralph

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 17 Sep 2010 17:17:48 +0200

[email-masked]:
> use and thus it is not available as TLD allocation. As far as I can
> tell ICANN would be happy to have documentation as to why .local is
> not to be allocated.

On one hand, having a locally scoped domain like .LOCAL is in some cases
a good idea. I'm in favour of the principal idea, and having it
documented and accepted by ICANN would be great. That way it could be
delegated to h-ll and back in the root name servers, and we could
off-load some of the bogus traffic from the roots.

On the down side, we have the process by which this specific name
(.LOCAL) has been established, i.e., by conscious volume deployment by
one or two major players. That is a denial of service attack. There is
no chance that anyone can register .LOCAL as their TLD now. What if
Belkin, Inc. or Netgear suddendly decided to deploy .BELKIN or .NETGEAR
in their equipment? There would be no need for them to register these
TLD names themselves and pay a frightful amount of money for the
pleasure. No one else can register them, so the are taken out of
circulation, and it wouldn't cost them a dime (at least in contributions
to ICANN). And then they all start to deploy code that send query storms
for each others' names. Not good.

So we have the unfortunate situation "You did wrong, but the result is
good. Don't do it again!". Have you ever tried telling your children
that? What was the outcome? ;-)

Actually I think that, unless it's already clearly documented in the
aforementioned documents, "we" *) should create the necessary
documentation to create a situation where .LOCAL is reserved for local
scope, and have ICANN make that delegation official. And delegate it to
127.0.0.1 or the AS112 servers or _somewhere_ other than the roots.

				Cheers,
				  /Liman

*) "we" is such a lovely loose term. What would your definition be in
   this case? ;-)

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 17 Sep 2010 13:59:56 -0400

On Fri, Sep 17, 2010 at 05:17:48PM +0200, Lars-Johan Liman wrote:
> in their equipment? 

At the very least, in the case of the former, I believe they did.
I've heard operators complain about it.

> 127.0.0.1 or the AS112 servers or _somewhere_ other than the roots.

ICANN has already determined that .local isn't getting registered by
anyone, so it seems it'd be a good thing to document it, even though I
agree with all of your worries about what might happen.  It might not
be a bad idea, also, to add a note about the history of .local
deployment, and note that the situation with respect to the stability
of the top level names has changed and that therefore people ought to
think carefully before re-enacting that history with another label.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Rob Austein <[email-masked]>
Date: Fri, 17 Sep 2010 19:53:17 -0400

> Did you mean "reuse of DNS" is emotional while the .local issue is technical?

olafur can speak for himself, but no, the statement as olafur wrote it
was correct.

stuart (aided and abetted by bill manning, who knows better but enjoys
making this kind of trouble) has insisted all along that what is now
called bonjour is just dns using multicast addresses.  it's not, and
never has been.  it's a protocol that fills some of the same tasks and
uses the same packet formats, but the scope is different, and several
of the fundamental concepts are very different (eg, the notion of
"authority" in the dns sense, the notion that any particular question
has a single answer regardless of which server you ask, etc).

stuart pretty much recognized this when he agreed to move bonjour to a
different port, which was, for me, the non-negotiable point.  on a
different port, it's weird and confusing and wrong that he insists on
pretending this is dns, but it's not likely to interact with normal
dns unless an implementor does something stupid; if he had left it on
the same port, it would have been actively harmful, because we would
have had multiple protocols using the same packet format on the same
port with different semantics.  joking aside, i was not seriously
proposing to challenge stuart's words on the topic, because he long
since yielded the point where it really mattered (the port number).

the remaining technical issue is that "unless an implementor does
something stupid" caveat.  because bonjour (and the ietf flavored
version of mdns, which is slightly different) use the same data
formats to accomplish some of the same tasks, there is some danger of
information leakage between the two.  to date, i am not aware of this
problem appearing in the wild, apparently because implementors to date
have refrained from being stupid, for which i am grateful.  but it is
a technical issue, and an ongoing risk.

while i do not disagree with the issues people have raised regarding
.local, .sink.arpa, .belkin, etc, they are mostly issues at layers 9
and above.  at the technical level, all that really matters is that
implementations agree on a suffix and that the suffix is not used for
other purposes in ways that cause protocol confusion.  the rights and
wrongs and precedents of whether a particular suffix was properly
allocated, was stolen, or was defensively allocated in response to
market share blackmail are layer 9+ issues (and not for the first time
either -- 127.0.0.0/8 is reserved because ucb stole it, iana allocated
it retroactively to avoid interop problems).

none of which is a request for anybody to do anything, just trying to
answer ralph's question.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Sep 2010 09:46:43 -0400

> olafur can speak for himself, but no, the statement as olafur wrote it

The issue of TLD names is emotional and Layer-9,
The issue of reuse of DNS packet format is the technical discussion.

> has a single answer regardless of which server you ask, etc).

The analogy I like to draw is that DNS is centralized name registration 
with "constant" answers.
MDNS is somewhere between anarchy and loose-cooperation.
IMHO both have their place.

Olafur

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Sep 2010 05:51:42 -0400

Thanks, Olafur, Rob, and all for your responses.

I haven't read anything that suggests I should not put the docs back into IETF last call and IESG review in their current state.  Do I have that right?

- Ralph

On Sep 20, 2010, at 9:46 AM 9/20/10, Olafur Gudmundsson wrote:

> The analogy I like to draw is that DNS is centralized name registration with "constant" answers.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Sep 2010 06:04:56 -0400

Rob - thanks for taking the time to write your detailed response.  

Is there any general or specific advice that should be written down somewhere to address this concern:

  i am not aware of this
  problem appearing in the wild, apparently because implementors to date
  have refrained from being stupid, for which i am grateful.

There are some technical aspects to the discussion of .local, .sink.arpa, .belkin that don't block the "Bonjour" docs from going forward.  .sink.arpa., in particular, is in discussion between the IESG and the IAB, but doesn't really have any impact here.

- Ralph

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 22 Sep 2010 15:34:39 +0200

> There are some technical aspects to the discussion of .local, .sink.arpa, .belkin that don't block the "Bonjour" docs from going forward.  .sink.arpa., in particular, is in discussion between the I…

That would be my assessment as well. And FWIW we are discussing sink.arpa

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam