Subject: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 01 Sep 2005 11:43:59 +0200

We're probably rehashing the DNSEXT discussion here, but I wasn't part of 
the DNSEXT discussion.....

LLMNR allows me to treat names in a different way than mDNS does.
If I have a name that I'm certain I own (this box is, with high certainty, 
the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR 
allows me to assert that name on a LAN even when the DNS is not available, 
or when that name is not currently asserted in the DNS.

mDNS, as I understand it, doesn't allow me to do that - I would have to 
assert "HALVESTR-W2K02.local", or "HALVESTR-W2K02.emea.cisco.com.local".

If we separate the concept of "name ownership" from "name assertion 
mechanism", and regard the DNS as just one mechanism of name assertion, 
then the problem reduces to "how do I prove that I have rights to the 
name", rather than "what name should I assert".

I think the LLMNR spec, which only talks about mechanism, is missing a 
reference to some other document (which may not exist, being too 
controversial to get written) laying out a theory of name ownership, in 
which both DNS and LLMNR fit as assertion mechanisms.

Not that I can say, based on this, that one of (LLMNR, mDNS) is better than 
the other. But it certainly emphasizes the fact that they're attacking the 
problem from completely different perspectives.

                           Harald

--On 31. august 2005 23:34 -0400 Keith Moore <[email-masked]> wrote:

> Dave Singer wrote:
>> The whole idea that 'real DNS' can arbitrarily pre-empt local name
>> resolution seems, well, wrong, and needs serious study for security
>> implications for the services using those names, no?
>
> The whole idea that local names should look like DNS names and be queried
> through the same APIs and user interfaces seems, well, wrong (or dubious
> at best), and needs serious study for the implications of applications
> using those APIs and the impact of such names on DNS, no?
>
> IMO, local names and a lookup service for local names would be extremely
> useful, but neither the names nor the query interface should look much
> like DNS - the names should look different because otherwise there's too
> much potential for confusion with DNS names, and the query service should
> look different because local name lookup service probably can't make the
> same kinds of consistency or stability assurances that DNS does.
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Ian Jackson <[email-masked]>
Date: Thu, 1 Sep 2005 10:50:01 +0100

Keith Moore writes ("Re: Last Call: 'Linklocal Multicast Name Resolution	(LLMNR)'	to   Proposed Standard"):
> The whole idea that local names should look like DNS names and be 
> queried through the same APIs and user interfaces seems, well, wrong (or 
> dubious at best), and needs serious study for the implications of 
> applications using those APIs and the impact of such names on DNS, no?

No.  Or at least, the point of having something like a link-local name
resolution protocol is that you can use the same interfaces to look up
the local names when using the link-local protocol, as you do when
looking up real DNS names when using the real DNS protocol.  That way
all the existing applications work and don't need to be changed.
Otherwise you would be suggesting building an entirely new protocol
and application stack, with changes to every application to support
the link-local scheme, which is obviously out of the question.

So what you're saying is that you're opposed to whole concept of
link-local name resolution.  And that therefore you favour LLMNR
because it doesn't (in your view) provide it !  Of course you are
wrong on this last point - LLMNR will be deployed behind the same APIs
currently used to do real DNS lookups.

I think that what you've done with your posting, really, is
demonstrate Stuart Cheshire's claim that LLMNR is for blocking effort !

> much potential for confusion with DNS names, and the query service 
> should look different because local name lookup service probably can't 
> make the same kinds of consistency or stability assurances that DNS does.

To say that, is to say that work on LLMNR should never have been
started.  There is no demand for a local name resolution protocol
which doesn't present a DNS API to applications.

You may well say that the whole concept of local name resolution, if
it must be presented to applications behind a DNS API, is a bad idea
and I have some sympathy with that view - but that's no argument for
LLMNR against mDNS !

Stuart seems to be claiming that the people who first told him to take
is mDNS away from the IETF, and LLMNR's authors, have that view - and
that LLMNR is the result of those people producing a protocol which is
intended to look enough like mDNS to fool people but is deliberately
_not_ intended to do any of the things that mDNS is good for !

Ian.

---

From: Peter Dambier <[email-masked]>
Date: Thu, 01 Sep 2005 11:50:34 +0200

Dave Singer wrote:
> I'm a by-stander on this discussion, maybe off-base or out of it -- but 
> something other than the undesirable traffic struck me.
> 
> Isn't it also true that I might *deliberately break* all sorts of things 
> by introducing 'blocking' names into DNS responses, so that an LLMNR 
> request is never issued.  So an ISP could 'grab' traffic that the users 
> thought was local, by replying to a DNS request in a proxy (or 
> converting a negative reply into an answer).

Yes,

we have done that accidently. We were told we have broken things on
windows by publishing ".local" in the Public-Root.

We stopped publishing that domain immediately. But yes, all you have
to do is send some random packets, resolving '.local' to the windows
box. The thing will happily cache them and next time ...

> 
> Also, ISPs might be tempted to start turning around DNS requests in 
> their proxies for names that they *think* should be answered by LLMNR, 
> returning resolution failure, so as not to send too much traffic 
> outbound.  This pre-empts the real DNS from ever actually replying.
> 

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [email-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: Peter Dambier <[email-masked]>
Date: Thu, 01 Sep 2005 12:38:10 +0200

<FAKE>

A friend just called to teach me how to spell LLMNR.
Sorry I can not do that without looking it up.

And he told me not to be so harsh with it. Yes they
need it. Their bot controler needs it.

No, you dont need a windows for the controler, MAC
or Linux does nicely. But the total cost of ownership
of a hijacked windows - you know ...

And he asked my not to tell you the details, like
windows caching used horseshoes or Netbios packets
remotely looking like DNS, or he would shot me or
ask the Apple Music Company (no, not the MAC people)
to do it :)

</FAKE>

Kind regards,
Peter and Karin Dambier

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Sep 2005 07:34:11 -0400

>> queried through the same APIs and user interfaces seems, well, 
>> wrong (or dubious at best), and needs serious study for the 
>> implications of applications using those APIs and the impact of 
>> such names on DNS, no?
> 
> 
> No.  Or at least, the point of having something like a link-local 
> name resolution protocol is that you can use the same interfaces to 
> look up the local names when using the link-local protocol, as you do
>  when looking up real DNS names when using the real DNS protocol. 
> That way all the existing applications work and don't need to be 
> changed.

False.  That way, you break various kinds of applications because you
violate assumptions that those applications quite reasonably made about
the APIs and services they were using, and you flood the DNS with
useless queries.  This is the same kind of problem that resulted from
introduction of NAT.

> the link-local scheme, which is obviously out of the question.

Actually, it's the only approach that makes any sense.  The idea that 
you can substitute a name service that works differently from what 
applications expect, without breaking some of those applications, is 
extremely naive.

> link-local name resolution.

No, I'm opposed to the concept of confusing resolution of local names
with resolution of DNS names.

> And that therefore you favour LLMNR because it doesn't (in your view)
>  provide it !

LLMNR isn't a competitor to mDNS.  They attempt to address different 
problems.

I favor adoption of LLMNR because in a world of disconnected and 
intermittently connected networks there's a need for applications to 
still be able to work - and being able to "work" includes being able to 
lookup the same DNS names that the applications would normally use in a 
connected network.

I favor discouraging use of mDNS because I believe it harms 
interoperability of Internet applications and operation of the DNS.  I 
would like to see a solution for the lookup of local names that did not 
have these characteristics.  If that solution can be derived from the 
mDNS protocol, that's fine with me, but it shouldn't overload the DNS 
lookup APIs nor should it borrow the DNS name syntax.

> Of course you are wrong on this last point - LLMNR will be deployed
> behind the same APIs currently used to do real DNS lookups.

LLMNR doesn't provide lookups for "local names" - it provides a local
service that can be used to query for attributes of DNS names.

>> IMO, local names and a lookup service for local names would be 
>> extremely useful, but neither the names nor the query interface 
>> should look much like DNS - the names should look different because
>>  otherwise there's too much potential for confusion with DNS names,
>>  and the query service should look different because local name 
>> lookup service probably can't make the same kinds of consistency or
>>  stability assurances that DNS does.
> 
> 

You appear to be confusing "a protocol for resolving names locally" with 
"a protocol for resolving local names".  They don't have to be the same 
thing.

> Stuart seems to be claiming that the people who first told him to 
> take is mDNS away from the IETF, and LLMNR's authors, have that view 
> - and that LLMNR is the result of those people producing a protocol 
> which is intended to look enough like mDNS to fool people but is 
> deliberately _not_ intended to do any of the things that mDNS is good
>  for !

LLMNR _looks like_ mDNS because both were intended for looking up names 
on a disconnected network, and because both were based on DNS.  That 
doesn't mean LLMNR _is trying to solve the same problem_ as mDNS.

Keith

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 Sep 2005 08:20:30 -0400

Maybe something like a Service Location Protocol, so that one could 
query by a combination of properties, not just name?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Sep 2005 15:03:33 +0200

On 1-sep-2005, at 13:34, Keith Moore wrote:

>> name resolution protocol is that you can use the same interfaces  
>> to look up the local names when using the link-local protocol, as  
>> you do

> useless queries.  This is the same kind of problem that resulted from

I find this a very curious position. Basically you're saying that the  
namespace for local lookups and global lookups must be so separate,  
that they can't even use the same code paths. I really don't see that  
having a clear separation between the two that is PART of the  
combined namespace (i.e., one or more global TLDs, one (or more?)  
local TLDs) would be insufficient here.

>> Otherwise you would be suggesting building an entirely new  
>> protocol and application stack, with changes to every application  
>> to support the link-local scheme, which is obviously out of the  
>> question.

> Actually, it's the only approach that makes any sense.  The idea  
> that you can substitute a name service that works differently from  
> what applications expect, without breaking some of those  
> applications, is extremely naive.

Which reasonable expectation are you talking about?

> I'm opposed to the concept of confusing resolution of local names

[...]

> intermittently connected networks there's a need for applications  
> to still be able to work - and being able to "work" includes being  
> able to lookup the same DNS names that the applications would  
> normally use in a connected network.

I don't understand how you can be in favor of LLMNR while at the same  
time being opposed to confusion between local and global ("DNS")  
names. In theory, I suppose it's possible that the information  
available over LLMNR and the information available from the DNS are  
100% consistent. In practice, this is of course completely  
impossible, and unless my memory is going faster than I thought, the  
draft doesn't even address this issue. So effectively, there will be  
a local namespace available over LLMNR and a global one available  
from the DNS, with an overlap somewhere betwee 0 and 1. An  
application then has no way to know which namespace provided a  
certain result.

> I favor discouraging use of mDNS

Let's be clear that this is a completely separate issue from whether  
the LLMNR protocol is the right answer to the right question.

> because I believe it harms interoperability of Internet  
> applications and operation of the DNS.

How, exactly?

> I would like to see a solution for the lookup of local names that  
> did not have these characteristics.  If that solution can be  
> derived from the mDNS protocol, that's fine with me, but it  
> shouldn't overload the DNS lookup APIs nor should it borrow the DNS  
> name syntax.

That seems unnecessarily conservative. Even if you find the "separate  
TLD" solution unacceptable, local names can still be put in a DNS  
class of their own. Classes were invented for exactly this reason, if  
memory serves.

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Sep 2005 14:14:03 +0100

On Thu, 1 Sep 2005, Harald Tveit Alvestrand wrote:
> If I have a name that I'm certain I own (this box is, with high certainty, the
> only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to
> assert that name on a LAN even when the DNS is not available, or when that
> name is not currently asserted in the DNS.

This kind of naming is not possible for ad-hoc networks without Internet
connectivity and without any domain name registration.

On the other hand, even centrally-managed naming is vulnerable to LLMNR
breakage. I have evidence (from MTA EHLO hostnames) that it is fairly
common for organizations to make up domain names for their internal
networks that do not currently exist but which may be delegated in the
future, such as orgint.com or organization.int. This is pretty stupid, but
it isn't disrecommended by Microsoft. http://support.microsoft.com/?id=254680
If a future product uses LLNMR instead of dynamic DNS they'll have a lot
of unhappy customers who find their internal domain has been delegated
since they chose their naming structure.

> mechanism", and regard the DNS as just one mechanism of name assertion, then
> the problem reduces to "how do I prove that I have rights to the name", rather
> than "what name should I assert".

The delegation structure of DNS proves the right to a name.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Alan Barrett <[email-masked]>
Date: Thu, 1 Sep 2005 15:22:55 +0200

> service that can be used to query for attributes of DNS names.

In other words, if I understand correctly, LLMNR is intended for
use in the situation where your printer is named something like
"myprinter.myrealdomain.tld", where "myrealdomain.tld" is a domain name
that you have the right to use in the DNS, but the DNS is not working
for you right now.  LLMNR is *not* intended for use in the situation
where your printer is named "MYPRINTER" or "myprinter.local", or
"myprinter.randomstuff".

--apb (Alan Barrett)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Sep 2005 15:38:05 +0200

> connectivity and without any domain name registration.

Apparently, LLMNR tries to remedy this situation by making it  
possible. However, the protocol doesn't address the issue of name  
ownership. We actually have protocols that assert name ownership more  
or less as a by product: x.509 and the like.

An LLMNR that requires responders to have an x.509 certificate for  
the name they're claiming to hold would at least solve this issue.  
Obviously such a protocol would be utterly useless in any kind of  
unmanaged environment where local lookups are most needed.

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Sep 2005 14:55:17 +0100

On Thu, 1 Sep 2005, Iljitsch van Beijnum wrote:
>
> I don't understand how you can be in favor of LLMNR while at the same time
> being opposed to confusion between local and global ("DNS") names. In theory,
> I suppose it's possible that the information available over LLMNR and the
> information available from the DNS are 100% consistent.

Is LLMNR supposed to work with RFC 3927 IPv4 link-local address
autoconfiguration? In which case it's also theoretically impossible for
LLMNR to be consistent with the DNS. (Consistency would require dynamic
DNS updates, and if they work your DHCP server should also be working, in
which case you won't have an RFC 3927 address.)

Tony.

---

From: Ian Jackson <[email-masked]>
Date: Thu, 1 Sep 2005 18:13:43 +0100

> LLMNR isn't a competitor to mDNS.  They attempt to address different 

We see to be living in some kind of Alice Through the Looking Glass
world here.  The llmnr drafts are even called `-mdns-' !

> lookup the same DNS names that the applications would normally use in a 

This is not what people are trying to deploy it for, and it is
distinctly unclear that LLMNR is at all the right answer for this
problem.

Ian.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 01 Sep 2005 20:08:44 +0200

--On 1. september 2005 14:14 +0100 Tony Finch <[email-masked]> wrote:

>> If I have a name that I'm certain I own (this box is, with high
>> certainty, the only one in the world named
>> HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to assert that name on a
>> LAN even when the DNS is not available, or when that name is not
>> currently asserted in the DNS.
>

it's certainly *possible* (if each participant has some relationship to a 
domain name owner). The question is whether it's *desirable*.

I see naming as 3 parts:

- I pick a name
- I assert that the name belongs to me
- You choose to believe it (or not).

With DNS names, "I pick a name" involves seeing which names are free in a 
DNS zone I have a relationship to (which may be dyndns.org, for instance), 
and doing the admin steps to reserve it.
"I assert" involves me putting it into a DNS zone, and loading that zone 
onto a DNS server, where you'll presumably pick it up.
"You choose" in the DNS case is because you believe (presumably) in the 
chain of servers between you, the root node and the authoritative server 
for my domain; in the LLMNR *or* mDNS case, it would be "because he's here 
and he says so".
This could be backed up with certificates if you wanted to, of course.

The difference between LLMNR and mDNS here seems to be that mDNS *requires* 
me to use two different names in the two different cases; LLMNR, while it 
certainly *permits* me to do so, does not *require* it.

This is descending into a philosophical debate... "what's in a name".......

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 01 Sep 2005 20:27:09 +0200

> certainly *permits* me to do so, does not *require* it.

Can I read this as "LLMNR SHOULD be used with domains in the .local
domain" ? Which puts it really in the same baliwick as mDNS (that is the
version that existed before that draft was written with the name mdns ;)

One can of course easily remove the check for the .local from the real
mDNS and use it for anything else too. Just change the MUST into a
SHOULD in the draft and everybody is happy.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Sep 2005 20:30:56 +0200

> With DNS names, "I pick a name" involves seeing which names are  
> free in a DNS zone I have a relationship to (which may be  
> dyndns.org, for instance), and doing the admin steps to reserve it.
> "I assert" involves me putting it into a DNS zone, and loading that  
> zone onto a DNS server, where you'll presumably pick it up.
> "You choose" in the DNS case is because you believe (presumably) in  
> the chain of servers between you, the root node and the  
> authoritative server for my domain; in the LLMNR *or* mDNS case, it  
> would be "because he's here and he says so".

What I'm missing in this story is how the application finds out who  
said so. So either you need to allow "Harald said so" for all  
applications or for none of them. That is not good.

> This could be backed up with certificates if you wanted to, of course.

Actually, it couldn't, as there is no provision for this in LLMNR.

> The difference between LLMNR and mDNS here seems to be that mDNS  
> *requires* me to use two different names in the two different  
> cases; LLMNR, while it certainly *permits* me to do so, does not  
> *require* it.

> This is descending into a philosophical debate... "what's in a  

Here's a philosophical question for you: is it right to force a  
philosophy on people? The trouble with LLMNR is that it has lots of  
repercussions for applications that don't want it, links that don't  
want it (that one is true for mDNS as well) and even server operators  
that don't want it.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 01 Sep 2005 15:31:05 -0400

At 02:08 PM 9/1/2005, Harald Tveit Alvestrand wrote:

>it's certainly *possible* (if each participant has some relationship 
>to a domain name owner). The question is whether it's *desirable*.
>
>I see naming as 3 parts:
>
>- I pick a name
>With DNS names, "I pick a name" involves seeing which names are free 
>in a DNS zone I have a relationship to (which may be dyndns.org, for 
>instance), and doing the admin steps to reserve it.

These are the same issues I recall asking about when dynamic DNS was 
being discussed/proposed. Any machine can make a claim they're 
whomever they want to be, and that request to insert mapping gets 
fired off to some distant DNS server who has no idea who the client 
is. I recall being told that any authorization to use a particular 
name was out of scope of the protocol. Thanking the person who told 
me this, I've made it a point to disable dynamic DNS in all 
envinronments since it's been available in running code. It's useless.

Now in the case of link local, it may or may not be useful for me to 
claim my machine is www.paypal.com and siphon off the requests of 
anyone dumb enough to listen to that. Or, perhaps, security 
considerations really are worth reviewing, even in a link local environment.

>*requires* me to use two different names in the two different cases; 
>LLMNR, while it certainly *permits* me to do so, does not *require* it.
>

Or, "how easy is it to spoof a name, and get the guy sitting next to 
me to fall for it."

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Sep 2005 16:35:45 -0400

On Thursday, September 01, 2005 15:31:05 -0400 Daniel Senie <[email-masked]> 
wrote:

> being discussed/proposed. Any machine can make a claim they're whomever
> they want to be, and that request to insert mapping gets fired off to
> some distant DNS server who has no idea who the client is. I recall being
> told that any authorization to use a particular name was out of scope of
> the protocol. Thanking the person who told me this, I've made it a point
> to disable dynamic DNS in all envinronments since it's been available in
> running code. It's useless.

Actually, it's not completely useless.  DDNS can be highly useful in 
specific deployments, where requests are authenticated and where there is a 
suitable authorization policy in place.  And yes, policy (authorization or 
otherwise) generally is out of scope for a well-designed protocol, and for 
good general-purpose implementations as well.

For example, here at CMU most of our authoritative nameservers are updated 
via DDNS; this allows us to map dynamically-assigned addresses to real 
hostnames, and to mix names of machines with dynamically- and 
statically-assigned addresses in the same domain.  The trick is that DDNS 
updates are all authenticated, and the only clients permitted to make such 
updates are the DHCP servers (which add and remove both forward and reverse 
records for dynamically-assigned hosts) and the tools which propagate 
changes from the network registration database (which maintain all the 
other records).

Of course, more precise policies are possible.  For example, a site like 
dyndns.org could allow a particular authenticated DDNS client to point its 
own name to any address it likes, but not to change any other name.

I suppose LLMNR might have its uses, too.  But I can't figure out what they 
are, and whether they are worth the significant amount of confusion and 
breakage which seem likely to result from widespread deployment of this 
protocol on the Internet.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 02 Sep 2005 00:17:37 +0200

--On torsdag, september 01, 2005 20:30:56 +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

> What I'm missing in this story is how the application finds out who  said
> so. So either you need to allow "Harald said so" for all  applications or
> for none of them. That is not good.

Yep.
In the DNS case, "the DNS server I asked said so".
In the LLMNR and mDNS case, "the machine that answered my multicast said 
so".

Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in 
additional data?) would seem to be one possibility to "prove" that the data 
being presented was "legitimate" under DNS delegation rules, even when you 
don't have a present connection to the Internet.

My imagination doesn't fly far enough at this time of night to figure out 
any relationship beteen a ".local" name and the term "legitimacy". But it's 
late in the evening, so my imagination is not flying very far - perhaps 
mDNS works because they deliberately abandoned the idea of name ownership.

YMMV.

                       Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 2 Sep 2005 00:58:14 +0200

On 2-sep-2005, at 0:17, Harald Tveit Alvestrand wrote:

> Flight of imagination: DNSSEC-Signed records (with the SIG/KEY  
> chain in additional data?) would seem to be one possibility to  
> "prove" that the data being presented was "legitimate" under DNS  
> delegation rules, even when you don't have a present connection to  
> the Internet.

Right. I'm looking forward to seeing a protocol that incorporates  
this notion.

> My imagination doesn't fly far enough at this time of night to  
> figure out any relationship beteen a ".local" name and the term  
> "legitimacy". But it's late in the evening, so my imagination is  
> not flying very far - perhaps mDNS works because they deliberately  
> abandoned the idea of name ownership.

Don't forget that the purpose of multicast DNS / Zeroconf /  
Rendezvous / Bonjour is service discovery. When you've discovered a  
service it's helpful to be able to refer to it by name, but the whole  
name lookup thing seems almost incidental.

> YMMV.

Well, isn't the purpose of a standards organization to make sure that  
even though your milage may vary, at least you know whether those  
miles are 1609 or 1852 meters in length?

---

From: Bill Manning <[email-masked]>
Date: Thu, 1 Sep 2005 18:38:23 -0700

On Sep 1, 2005, at 15:17, Harald Tveit Alvestrand wrote:

>> said
> In the LLMNR and mDNS case, "the machine that answered my multicast 
> said so".
>
> Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain 
> in additional data?) would seem to be one possibility to "prove" that 
> the data being presented was "legitimate" under DNS delegation rules, 
> even when you don't have a present connection to the Internet.
>
> My imagination doesn't fly far enough at this time of night to figure 
> out any relationship beteen a ".local" name and the term "legitimacy". 
> But it's late in the evening, so my imagination is not flying very far 
> - perhaps mDNS works because they deliberately abandoned the idea of 
> name ownership.

	the TBDS work presumed a shared, common name space (the DNS as we know 
it today) - where each node is "imprinted" with its FQDN
	and is tagged w/ an x509 cert.  The DNS delegations are signed.   a 
change w/ TBDS is that each node runs a DNS server, not just a
	stub resolver.  so it can ask questions and cache answers.... and when 
it (the node) runs "into" an authoritative server for something 
"higher"
  	in the heirarchy, it can "flush" the more specific data in favor of 
the authoritative stuff.   This does not prevent random nodes from 
trying to
	spoof being who they are not, but w/ the extra data (signed 
delegations & x509 certs) the receiving node does have somewhat more 
data
	on which to evaluate the "viability" of any given reply ...  With 
TBDS, it is also possible to assert extensions to the namespace, but 
they would
	only be honoured by parties that share the same security/trust "hooks" 
  e.g.  if we both know the "secret password" then our use of the 
.piglet  TLD
	works.... for us.  Others ignore these queries.   mDNS seems to have 
taken this idea but restricted it to a single extention, e.g. .local

	(and yes, there are many fine minefields here,  but the project ran 
out of funding)

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Sep 2005 12:07:10 +0100

> don't have a present connection to the Internet.

How can you verify the signature without an Internet connection with which
to fetch the key?

Why does it make sense to strive for globally-unique names when all that
matters is uniqueness on the local link?

Tony.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 02 Sep 2005 07:24:01 -0400

In message <[email-masked]>, Tony Fin
>How can you verify the signature without an Internet connection with which

If you have the zone key, you can do the verification offline.
>matters is uniqueness on the local link?
Bellovin's Laws of Networking:
	1	Networks interconnect.
	2	Networks *always* interconnect.
	3	Interconnection happens from the edges, not the center

What's going to happen to your link-local uniqueness when someone adds 
a bridge? 

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Sep 2005 12:46:17 +0100

> If you have the zone key, you can do the verification offline.

How can you be expected to have the zone key of some random name that just
turned up on your network?

> What's going to happen to your link-local uniqueness when someone adds

The same issue arises with new devices turning up on the network. Both
LLMNR and mDNS have mechanisms for dealing with uniqueness changes.

Tony.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 02 Sep 2005 22:14:38 +0900

> If you have the zone key, you can do the verification offline.

How can you update the (root?) zone key timely, upon key rollover or,
worse, accidental publication of the key?

							Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 02 Sep 2005 14:46:18 +0200

At 13:34 01/09/2005, Keith Moore wrote:
>You appear to be confusing "a protocol for resolving names locally" 
>with "a protocol for resolving local names".  They don't have to be 
>the same thing.

I fail to see what these propositions bring that local name servers 
with small addition in db.local and caching strategy could not be 
used to provide? Or am I misreading  them?
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 02 Sep 2005 15:20:06 +0200

> turned up on your network?

you can always ask the guy for the zone key (and its signature).
you have to get a certificate chain that ends up at a root key you trust, 
of course.

Reducing the problem to a previously unsolved problem.... but if you only 
care about whether or not it's locally unique, you don't CARE whether it's 
authentic or not, so you don't have to fetch anything....
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 02 Sep 2005 17:00:03 +0200

At 20:30 01/09/2005, Iljitsch van Beijnum wrote:
>philosophy on people?

Dear Iljitsch,
I started that debate with Harald in 2000 at the DNSO/GA over the 
understanding of "global". This mares many issues. Harald says "yes", 
I say "no", but I understand the need of "yes" on occasions, when the 
users want it and for transitions. Like in the Roman constitution.

Why not once for all gather all the cons and pros and call for an IAB 
guidance to get documented if the Internet is a directive system or 
not, or can be distinctly both, at the same time, or at distinct 
times. I think it can be both if the concerned areas are clearly defined.

For example, could classes help in this case to create a real but 
crossable boarder? I don't know, just an hint to address the security concern.
jfc