Subject: [homenet] Name service design principles: a proposal

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 29 Jun 2012 11:06:20 -0400

After the Homenet meeting in Paris I realized that the group needs
good principles for its name-space work. The principles in -arch-02 are
a good start but IMHO not sufficient.
It makes not sense to be proposing/evaluating solutions when there
are no agreed upon principles/requirements.

The chairs have been bugging me to follow up with a contribution.
Below is my attempt at defining as compactly/broadly as
possible design principles for Name services:

a) Homenet name-service MUST NOT interfere with Internet name-service

b) Homenet name-service MUST NOT be in Internet name space.

e) Homenet name-service MUST function throughout the whole "site"

c) Homenet name-service SHOULD support both lookups and discovery

d) Homenet name-service SHOULD be considerate of bandwidth usage

e) Homenet name-service MUST allow segmentation of "name space" for
different classes/groups/cliques of applications/devices

g) Homenet name-service SHOULD allow both broadcast service as well as
    more traditional lookup service.

I'm expecting a lively discussion on this topic :-)

     Olafur

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2012 11:34:22 -0400

So, let's compare this with what I talked about during the Paris WG meeting:

* Disconnected operation ("fate sharing"): name resolution for reachable
devices continues if the local network is disconnected from the global
Internet

* Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the
global DNS namespace

* Representation in the global DNS namespace, for access from off-net

* Unmanaged operation

* Efficient message utilization: for example, keep unwanted traffic
off of an IEEE802.15.4 network

Merging those points with comments in-line...

> a) Homenet name-service MUST NOT interfere with Internet name-service

"Internet name-service"?  Do you mean "DNS"?  "Co-exist" might be a
better word.  Users want a single interface into naming and don't
want to have to differentiate between "naming stuff on my local network"
and "naming stuff in the Internet".  Ted Lemon raised this issue much
more eloquently during the WG meeting.

I'll add my first bullet here, rephrased a little:

a.1) Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the
Internet name-service

> b) Homenet name-service MUST NOT be in Internet name space.

How are things in the home identified from outside the homenet?

> c) Homenet name-service SHOULD support both lookups and discovery

What do you mean by "lookups and discovery"?  Are they different
forms of name resolution?

> different classes/groups/cliques of applications/devices

What requirements is this segmentation intended to satisfy?

>   more traditional lookup service.

Seems like an implementation detail to support a higher level requirement
like "must not require a centralized registration/resolution service".

Two operational points from my list:

h) Disconnected operation ("fate sharing"): name resolution for reachable
devices continues if the local network is disconnected from the global
Internet

i) Unmanaged operation

> I'm expecting a lively discussion on this topic :-)

OK, I've contributed to the discussion.

- Ralph

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

---

From: Benjamin Kerensa <[email-masked]>
Date: Fri, 29 Jun 2012 10:48:35 -0700

On Fri, Jun 29, 2012 at 8:06 AM, Olafur Gudmundsson <[email-masked]> wrote:

> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

I think the above design principles seem pretty precise and common sense
I guess my only question is in the case of segmentation of "name space" for
various classes is there going to be limitations to the segmentation or
policies surrounding cases where segmentation occurs in the "name space".

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 29 Jun 2012 14:19:34 -0400

> How are things in the home identified from outside the homenet?

They will have to have two names one internal and one externally visible.

> forms of name resolution?

lookup is direct query,
discovery may use broadcast/multicast messages or a service where 
applications register in order to be found.

> What requirements is this segmentation intended to satisfy?

Think kitchen appliances and media center do they ever need to talk ?
I worry that if they talk, that one day I open the refrigerator and grab 
a beer, now suddenly the music changes to polka.

But seriously, I want to be able to drop/ignore messages, that nothing 
on the device cares about, at the lowest layer possible.

> like "must not require a centralized registration/resolution service".

Maybe, but as some people seem to assume that only one and not the other 
operating mode be used I wanted to put this on the table.

> devices continues if the local network is disconnected from the global

This is a violation of my principle b) home net names should always work 
if the supplier of the data is awake.

I was debating to put in something about supporting devices that are 
only sometimes on but decided to keep that out.
> i) Unmanaged operation

This is a good one

	Olafur

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jun 2012 11:27:41 -0700

> How are things in the home identified from outside the homenet?

Maybe I can add some fuel to Olafur's fire. I'd like to say that the
homenet name service MUST be DNS.

This may sound like heresy, but here's my reason: I want the ability
to transition from a private name space to a public name space with
minimal fuss. I don't want a different naming mechanism that has
its own oddities just because I can't think up a clever domain name
for my home net that goes into the global DNS when I'm forced to
install my router. When I'm finally inspired, I want to be able to make
that transition and then worry about the split horizon implications
(if I even get around to caring about such a thing).

So perhaps, we can make use of statistically unique naming to keep
things from bumping into one another, etc... this is sort of off the cuff,
but the real point is not having to transmogrify one naming scheme into
another. Yuck.

Mike

---

From: Don Sturek <[email-masked]>
Date: Fri, 29 Jun 2012 11:53:12 -0700

Hi Michael,

The difficulty with your proposal is that the homenet address space is now
connected to the wider internet.

Services in the home must be discoverable without any internet
connectivity.

Don

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jun 2012 12:18:53 -0700

> connected to the wider internet.

It wasn't a proposal of a solution, so much as plea to not make my
life more difficult trying to keep track of the difference between
"in" and "out" naming systems. We've done a pretty good job of
teaching the world about fqdn's to the point that seeing unqualified
names makes me wonder what they are and whether they even refer
to anything Internet-like. And of course, I want to have a flip of
the switch if I decide to make them Internet-wide visible.

> Services in the home must be discoverable without any internet

By discoverable, I assume that you mean that my home name translation
still needs to work when I don't have connectivity. That seems like a
perfectly reasonable requirement too.

Mike

---

From: Benjamin Kerensa <[email-masked]>
Date: Fri, 29 Jun 2012 12:20:40 -0700

>>> but the real point is not having to transmogrify one naming scheme into
            Seems like a smart move

-- 
Benjamin Kerensa
http://benjaminkerensa.com
"I am what I am because of who we all are" - Ubuntu

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Jun 2012 12:58:03 -0700

On Jun 29, 2012, at 11:27 , Michael Thomas <[email-masked]> wrote:
> 
> Maybe I can add some fuel to Olafur's fire. I'd like to say that the homenet name service MUST be DNS.

Let's go further.  Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it stands a decent chance of being a published RFC by the time HOMENET finishes its first round of major work.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

[*] <http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Jun 2012 16:07:55 -0400

> > possible design principles for Name services:
You don't state the usual "strong bias toward existing standards/running
code",
so I assume it goes without saying ;-)

> I'd go further and say users want a single way to THINK about local and
wide-area names and resolution.  Some of us with a strong bias toward a
DNS-like solution have been looking at this issue for 2+ years in other
contexts.

> Is the desire here to preserve the "main" element of the name (e.g. the
leftmost label of a FQDN)?

> It would be helpful Olafur if you could provide some motivation for these
requirements.   I agree that local naming and discovery should be possible
without requiring a directory server.  But if I can access
myHost.myDomain.net
from outside, why not from inside the home net?

> > d) Homenet name-service SHOULD be considerate of bandwidth usage
Could this be restated as "the bandwidth requirement for discovery should
remain
relatively constant as the network scales"?  The cost of achieving this may
be
to add additional elements like proxies or directory servers to the network.

> This may be tricky in practice, and should be prioritized relative to
other requirements.
We discuss methods in http://tools.ietf.org/html/draft-vanderstok-core-dna.
 If
this requirement must be met by a multicast protocol, the fact is that many
OSs
only support a handful of multicast addresses.

> An important point here is that existing discovery protocols are not going
away any
time soon and could be leveraged to "seed" a directory server with records.

Two operational points from my list:
> And if the local directory server goes down...

> Yes!!!

-K-

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2012 16:09:05 -0400

> Let's go further.  Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it sta…

Well, DNS-Based Service Discovery addresses just one kind of requirement: listing entities that provide a certain kind of service; perhaps generalizable to resolution based on a characteristic or set of characteristics that might return more than one response to the resolution request.  At some point, there needs to be a mechanism for resolving an identity to a single IP address.

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Jun 2012 16:19:20 -0400

On Fri, Jun 29, 2012 at 4:09 PM, Ralph Droms <[email-masked]> wrote:

> > Let's go further.  Let's say that it must be DNS-Based Service Discovery
> [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for
> 199 days at this point, so one imagines that it stands a decent chance of
> being a published RFC by the time HOMENET finishes its first round of major
> work.
>
> Hear, hear!

> Well, DNS-Based Service Discovery addresses just one kind of requirement:
> listing entities that provide a certain kind of service; perhaps
> generalizable to resolution based on a characteristic or set of
> characteristics that might return more than one response to the resolution
> request.  At some point, there needs to be a mechanism for resolving an
> identity to a single IP address.
>
> Actually, a Multicast DNS responder (mDNS is the multicast version of
DNS-SD)
will allow you to resolve A, AAAA records:

Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 _http._tcp.local
PTR     <<<< We first discover web servers

; <<>> DiG 9.7.3-P3 <<>> -p 5353 @224.0.0.251 _http._tcp.local PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33690
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;_http._tcp.local. IN PTR

;; ANSWER SECTION:
_http._tcp.local. 10 IN PTR
Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local.

;; ADDITIONAL SECTION:
Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. 10 IN SRV 0
0 80 HP4C0EA4.local.
Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. 10 IN TXT ""
HP4C0EA4.local. 10 IN A 192.168.1.31
HP4C0EA4.local. 10 IN AAAA fe80::dad3:85ff:fe4c:ea4

;; Query time: 20 msec
;; SERVER: 192.168.1.31#5353(224.0.0.251)
;; WHEN: Fri Jun 29 16:13:10 2012
;; MSG SIZE  rcvd: 168

Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 HP4C0EA4.local A
  <<<< We can also resolve the host record

; <<>> DiG 9.7.3-P3 <<>> -p 5353 @224.0.0.251 HP4C0EA4.local A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40117
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;HP4C0EA4.local. IN A

;; ANSWER SECTION:
HP4C0EA4.local. 10 IN A 192.168.1.31

;; Query time: 1 msec
;; SERVER: 192.168.1.31#5353(224.0.0.251)
;; WHEN: Fri Jun 29 16:13:39 2012
;; MSG SIZE  rcvd: 48

Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @192.168.1.31 HP4C0EA4.local A
   <<<< We can just as easily unicast the query

; <<>> DiG 9.7.3-P3 <<>> -p 5353 @192.168.1.31 HP4C0EA4.local A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32090
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;HP4C0EA4.local. IN A

;; ANSWER SECTION:
HP4C0EA4.local. 10 IN A 192.168.1.31

;; Query time: 2 msec
;; SERVER: 192.168.1.31#5353(192.168.1.31)
;; WHEN: Fri Jun 29 16:17:47 2012
;; MSG SIZE  rcvd: 48

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2012 16:26:04 -0400

On Jun 29, 2012, at 4:07 PM 6/29/12, Kerry Lynn wrote:

>> You don't state the usual "strong bias toward existing standards/running code",

Yes ... which is roughly the message I took from Ted's contribution at the WG meeting.  That way of thinking about local and non-local names might even be a GUI or some other way of presenting a list of choices to a user.  As long as there as the information is "just right" (not too much and not too little), the underlying resolution methods can be hidden.
 
> leftmost label of a FQDN)?

Roughly speaking.  I think what's needed is some equivalent of RFC 1918 addressing: a way of doing name resolution that has a "local" context without needing to have a globally unique name for that context.

> without requiring a directory server.  But if I can access myHost.myDomain.net

> Could this be restated as "the bandwidth requirement for discovery should remain
> relatively constant as the network scales"?  The cost of achieving this may be

Or, perhaps, bandwidth requirement scales with the number of devices interested in the specific queries and responses.  Assuming the name-service functions across the whole site, I was thinking in particular of the case of an IEEE 802.15.4 network of constrained devices that don't need to see all the name-service traffic for printers, mobile devices, etc.
> This may be tricky in practice, and should be prioritized relative to other requirements.
> We discuss methods in http://tools.ietf.org/html/draft-vanderstok-core-dna.  If
> this requirement must be met by a multicast protocol, the fact is that many OSs
> An important point here is that existing discovery protocols are not going away any

...if there is one.

> Yes!!!

A universal point of agreement?

- Ralph

---

From: Ray Hunter <[email-masked]>
Date: Fri, 29 Jun 2012 22:30:15 +0200

> but the real point is not having to transmogrify one naming scheme into
There are a number of parallels from Homenet to small and large 
enterprises who declared UDI from the global DNS (and set up their own 
private root servers) for any number of reasons. Similarly for WINS and 
mDNS users.

So maybe a useful approach would be to ask "what's wrong with DNS today 
that it can't satisfy all of the requirements mentioned" or "Why did 
these people declare UDI in the first place?" or "Why did they invent 
that stuff?" and more to the point "Can it be fixed?"

Some of my answers to those questions would be:

1. Availability: Undesirability of fate sharing

I don't want my media streamer and other devices like a smoke alarm 
becoming locally unavailable because I change provider or the Internet 
link is down for an extended period.

2. Easy roll out and maintenance

I can't see Homenet being able to implement DNSSEC today, so we have to 
be aware of cache poisoning in Homenet and how to address that if DNS is 
the chosen solution.

3. One single namespace for all destinations.Coexistence with global DNS.

Strong desire to integrate into the global DNS naming tree. Single name 
space, single query type, no two way synchronization of separate name 
spaces. I make no statement of preference on whether the transport has 
to be native DNS within the home.

4. Support of Highly Mobile out of the shrinkwrap

Changing environments can be especially problematic for highly mobile 
nodes with flexible tethering, such as iDevices. They should just work 
in and out of the home, as you move within range of your Homenet wireless.

5. Integrity: Integrated Security

We should be aware of security issues with a .local style namespace over 
whatever transport (your iDevice connecting to my evil .local device 
posing as a friendly fileserver because you're walking past my open home 
network). So there would need to be some extra device pairing if a 
.local namespace is used, or see (5).

6. Independent Local Trust Anchor

Strong desire to avoid a heavyweight trust anchor tied into the public 
DNS. That would be another important point for me if starting from 
scratch. Perhaps the ability to insert a private trust anchor at some 
nominal point on the DNS tree that I can use to authenticate between my 
own devices, other than being limited to a trust anchor derived from the 
DNS root. I'm pretty sure ISP's won't want to have people phoning their 
help desks asking about key rotation problems or with how-to questions 
about key signing keys in Homenet.

7. Integrated Low Power Version

Ability for low power devices to sleep for extended periods built in 
from the get go (naming gateway? naming proxy responder?)

8. Confidentiality: Name space hiding

Ability to "hide" a portion of the name space to discourage scanning.

regards,
RayH

---

From: Dave Taht <[email-masked]>
Date: Fri, 29 Jun 2012 13:52:40 -0700

On Fri, Jun 29, 2012 at 1:30 PM, Ray Hunter <[email-masked]> wrote:
> There are a number of parallels from Homenet to small and large enterprises
> who declared UDI from the global DNS (and set up their own private root
> servers) for any number of reasons. Similarly for WINS and mDNS users.
>
> So maybe a useful approach would be to ask "what's wrong with DNS today that
> it can't satisfy all of the requirements mentioned" or "Why did these people
> declare UDI in the first place?" or "Why did they invent that stuff?" and
> more to the point "Can it be fixed?"
>
> I don't want my media streamer and other devices like a smoke alarm becoming
> locally unavailable because I change provider or the Internet link is down
> for an extended period.

You shouldn't outsource your dns to your provider but be running a
local cache and authorative server.

As for the link being down for an extended period, that is something
of a problem in the general case. I'd harden this requirement to your
network should be able to boot and run independently of the internet
being available or not. This is certainly the case with mdns, not so
much with dns.

> I can't see Homenet being able to implement DNSSEC today, so we have to be
> aware of cache poisoning in Homenet and how to address that if DNS is the
> chosen solution.

I'm puzzled. cerowrt and iscwrt have had dnssec for a year now...
while bind is the most heavyweight
daemon in the mix (about 10MB just to start, about 20MB with a full
cache), it's certainly possible to run dnssec on your typical consumer
router, and seems possible to add DNSSEC to something more lightweight
like dnsmasq. At least a few applications implement dnssec too,
there's a plugin for firefox
that I know of.

> spaces. I make no statement of preference on whether the transport has to be
> native DNS within the home.

This sort of conflicts with 8 below.

> Changing environments can be especially problematic for highly mobile nodes
> with flexible tethering, such as iDevices. They should just work in and out
> of the home, as you move within range of your Homenet wireless.

Hard problem that crosses not just dns, but applications, the network
stack and cryptography. The app that I love that implements this
functionality fairly well is mosh, and even then it only works
presently on ipv4 and that with public ip addresses.

> whatever transport (your iDevice connecting to my evil .local device posing
> as a friendly fileserver because you're walking past my open home network).
> So there would need to be some extra device pairing if a .local namespace is
> used, or see (5).

Drive by wifi exists independently of the .local convention. It's a
network, not naming
problem.

> Strong desire to avoid a heavyweight trust anchor tied into the public DNS.
> That would be another important point for me if starting from scratch.
> Perhaps the ability to insert a private trust anchor at some nominal point
> on the DNS tree that I can use to authenticate between my own devices, other
> than being limited to a trust anchor derived from the DNS root. I'm pretty
> sure ISP's won't want to have people phoning their help desks asking about
> key rotation problems or with how-to questions about key signing keys in
> Homenet.

Having a decent trust anchor to start with with any system would be
good. One of my own issues is that the cert system is so broke that
the most secure certs are the ones you generate yourself, but those
throw an error in your browser by default.

> Ability for low power devices to sleep for extended periods built in from
> the get go (naming gateway? naming proxy responder?)
>

-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
with fq_codel!"

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jun 2012 13:57:15 -0700

> Let's go further.  Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it sta…

James -- I'm not that familiar with dns-sd and it's been 1000 years since i've
thought about nbp, but services aren't the only thing I have in my home. Or
at least I wouldn't necessarily think of some things grouped together as named
services like, oh say, my light switches. Maybe I'd want to think of them that
way, but maybe I wouldn't. So I'm not sure  that I'd be comfortable saying that
it's a particular flavor of DNS like DNS-sd.

That, and I can't tell whether this makes it easier, harder or neutral on my
original request that making the transition from a private name space to a
public one trivial. Can I use service discovery from across the Internet to get
back to things in my home assuming that I have a registered domain? Sorry
for the ignorance, but nbp was a decidedly localized protocol.

Mike

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 14:09:57 -0700

> Well, DNS-Based Service Discovery addresses just one kind of requirement: listing entities that provide a certain kind of service; perhaps generalizable to resolution based on a characteristic or s…

Why? if the DNS gives multiple answers, they're intended to be 
equivalent for that service.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 14:10:48 -0700

Hi, all,

Not a bad list - but I wonder why it applies to Homenet, and not the 
Internet in general?

Is there anything here that's homenet-specific? Either way, it'd be 
useful to be clear about that...

Joe

On 6/29/2012 10:48 AM, Benjamin Kerensa wrote:
>
>
> On Fri, Jun 29, 2012 at 8:06 AM, Olafur Gudmundsson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     _________________________________________________
>     homenet mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/homenet
>     <https://www.ietf.org/mailman/listinfo/homenet>
>
>
>
> I guess my only question is in the case of segmentation of "name space"
> for various classes is there going to be limitations to the segmentation
> or policies surrounding cases where segmentation occurs in the "name space".
>
>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2012 17:11:57 -0400

On Jun 29, 2012, at 5:09 PM 6/29/12, Joe Touch wrote:

> Why? if the DNS gives multiple answers, they're intended to be equivalent for that service.

Sure...I should have said "resolve an identity to an IP address or address(es)".

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Jun 2012 17:21:46 -0400

> James -- I'm not that familiar with dns-sd and it's been 1000 years since

Well, you're in luck.  There's an O'Reilly book called "Zero Configuration
Networking" that explains all...

> Here's a short list of services that are already defined:
http://www.dns-sd.org/ServiceTypes.html

I will shortly be refreshing
http://tools.ietf.org/html/draft-lynn-core-discovery-mapping/
to describe a way to use mDNS/DNS-SD to discover REST web service
interfaces within a device.  So if you think of your light switches in that
way,
you're covered.

> I can point you to http://tools.ietf.org/html/draft-cheshire-dnsext-nbpfor historical
background, but best to just read up on DNS-SD.  As far as transitioning
from
private to public domains, that's where resolve.conf helps.  Also, see
http://dyn.com/support/bonjour-and-dns-discovery/

-K-

Mike

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Jun 2012 15:07:29 -0700

On Jun 29, 2012, at 13:57 , Michael Thomas <[email-masked]> wrote:
> 
> Can I use service discovery from across the Internet to get back to things in my home assuming that I have a registered domain?

Last login: Fri Jun 29 14:52:05 on ttys000
zephyr ~ 501$ ssh -p 22 [email-masked].
Last login: Fri Jun 29 14:55:24 2012 from fd3a:a6fe:48b6:8b35:c1aa:9b69:17ce:fb01
zeece ~ 501$ 

I could post pictures of what it looks like when I go to configure my Time Capsule at home remotely from my desk in Cupertino, but that would be a waste of valuable IETF remailer resources.  Suffice to say it works like this:

 p1. Launch the AirPort Utility (which is used for configuring Time Capsule).

 p2. Click on "Other Base Stations" button in the upper right of the main window.

 p3. Choose "James's Home Time Capsule" from the pop-up menu.

 p4. A configuration window opens.  Make changes.  Click "Save" and the window closes.

Step p2 above starts the browse for AirPort and Time Capsule configuration services in the list of domains my system is automatically configured to search, which includes my iCloud member domain, but it could include any other domains.  The browse operation queries for PTR records containing names of SRV records, and it results in the list presented in the pop-up menu.

Step p3 above starts the locate for the chosen Time Capsule service instance.  The locate operation queries for SRV records, as well as the A and/or AAAA records corresponding to the hostname part of the service resources.

Step p4 above starts parallel TCP connections to one or more of the destination addresses returned by the locate operation, in a sensible order and possibly in parallel, until one of them connects or they all fail.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Jun 2012 08:08:15 +0100

On 2012-06-29 19:19, Olafur Gudmundsson wrote:
...
> They will have to have two names one internal and one externally visible.

Exactly. This has been standard practice in enterprise networks
using standard DNS software for years, and is exactly analogous to
ULAs and globally-routeable GUAs. The internal name should IMHO
be syntactically identical to an FQDN but will not resolve off-site.

This does not need to break the hierarchical purity of the DNS
name space, just as ULAs do not break the IPv6 address hierarchy.

(By contrast, RFC 1918 and .local do break their respective
hierarchies.)

> the switch if I decide to make them Internet-wide visible. 

+1

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sat, 30 Jun 2012 11:22:01 +0200

Thanks for the reply. See inline.
> Dave Taht <mailto:[email-masked]>
> 29 June 2012 22:52
> On Fri, Jun 29, 2012 at 1:30 PM, Ray Hunter<[email-masked]>  wrote:
>> Michael Thomas wrote:
hmm. Ok in corporates. But SME & Homenet?
> being available or not. This is certainly the case with mdns, not so
Good point. Should be capable of working stand alone, or co-existent 
with global DNS.

Perhaps I'm being naive, but I see no fundamental reason why the same 
zone file can't be mounted at two points on the DNS tree. Once for a 
.homenet. root (for local resolution independent of the global internet) 
and once for a globally derived root (for resolution from outside of 
Homenet). Resolvers would have two defaults in their search list, first 
.homenet space and then one for global name space.

Isn't that better than trying to run/export/import/synch 2 completely 
independent name resolution protocols?

> there's a plugin for firefox
Perhaps try explaining to your mom what she needs to do for 
best-practice zone management, and how to update key signing keys etc. 
when changing providers ?
> This sort of conflicts with 8 below.
Yes. These requirements are not always consistent. Perhaps that's why we 
have so many name resolution protocols.
> presently on ipv4 and that with public ip addresses.
True. But it's what consumers expect.
> Drive by wifi exists independently of the .local convention. It's a
Maybe we can agree that caching of a .local style namespace that is not 
uniquely globally identifiable is problematic (for highly mobile nodes) 
and needs to be addressed.

> throw an error in your browser by default.
I presume you're more than marginally acquainted with Active Directory.
> Ray Hunter <mailto:[email-masked]>
> 29 June 2012 22:30
>
> private root servers) for any number of reasons. Similarly for WINS 
> and mDNS users.
>
> So maybe a useful approach would be to ask "what's wrong with DNS 
> today that it can't satisfy all of the requirements mentioned" or "Why 
> did these people declare UDI in the first place?" or "Why did they 
> invent that stuff?" and more to the point "Can it be fixed?"
>
> I can't see Homenet being able to implement DNSSEC today, so we have 
> to be aware of cache poisoning in Homenet and how to address that if 
> DNS is the chosen solution.
>
> Strong desire to integrate into the global DNS naming tree. Single 
> name space, single query type, no two way synchronization of separate 
> name spaces. I make no statement of preference on whether the 
> transport has to be native DNS within the home.
>
> We should be aware of security issues with a .local style namespace 
> over whatever transport (your iDevice connecting to my evil .local 
> device posing as a friendly fileserver because you're walking past my 
> open home network). So there would need to be some extra device 
> pairing if a .local namespace is used, or see (5).
>
> nominal point on the DNS tree that I can use to authenticate between 
> my own devices, other than being limited to a trust anchor derived 
> from the DNS root. I'm pretty sure ISP's won't want to have people 
> phoning their help desks asking about key rotation problems or with 
> how-to questions about key signing keys in Homenet.
>
> ------------------------------------------------------------------------

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 30 Jun 2012 22:27:43 -0400

In message <[email-masked]>

+1

> but the real point is not having to transmogrify one naming scheme into

I'm not sure that some of the respondents later in this thread
understand what DNS can do already with no changes.

1.  An important domain that is visible to the outside world can also
    remain available even if the Internet is not available.

    Local hosts which use DHCP can be told to query a local DNS cache.
    That DNS cache can be a DNS secondary (or primary) to your
    enterprise's domain, or a local domain.  As a primary, it never
    expires.  As a DNS secondary it can continue to serve DNS queries
    for the domain when the Internet is unavailable until the zone
    file expires (typically days).

    Example: In every well run enterprise today, the local DNS caches
    are DNS primary or DNS secondary for the local domain.

2.  A local domain can be either visible to the Internet or not
    visible.  It is also possible to provide different results locally
    and to the Internet.

    You can create a .local domain that can't be reached except by 

    The NS record available to the outside world can point to a
    different nameserver than the set of nameservers for that same
    domain that are used internally.  This gets annoying for remote
    users when switching the enterprise VPN on and off, but otherwise
    it works just fine.  [btw- An alternate that avoids the VPN issue
    is to create site specific subdomains that are not visible to the
    outside world.]

    Example: Most enterprises reuse their domain internally, serving
    up their name resolutions to private addresses, but only provide
    the name resolution for the hosts with global addresses to the
    outside world.

3.  Devices can already register their own host name to IP address
    mapping.

    Dynamic DNS is far from a new concept.  A DHCP client can provide
    its own host name when retrieving an address.  The DHCP server can
    be coupled to a DNS cache which adds the forward (and optionally
    reverse) DNS mappings to the appropriate zones until the DHCP
    lease expires.

    Example: ISC dhcpd and ISC bind can be coupled in this way.  [Not
    intended as an endorsement.  No doubt many others can as well.]

Others have suggested DNSSEC.  That may conflict with the zero
configuration goal unless a trust anchor is supplied at shipment time.
Zero configuration and the existing cert hierarchy seem to me to be
conflicting goals, but I'd be open to being told otherwise.

The "zero configuration" goal implies that the default configuration
for the homenet router in isolation (no other routers discovered) must
be to serve as a DNS cache, offer a .local domain, and add an entry
into the .local domain for any DHCP lease allocated.  If other homenet
routers are discovered, then some form of election is needed to figure
out a DNS primary for the .local domain.

One could argue that the homenet router could also get a proper domain
name from the provider, but most providers will give their domain name
in response to DHCP queries.  If the provider is know to provide a
useful domain name, then trusting the domain offerred by the provider
can be a simple configuration override.

Simple configuration could substitute a real domain name for the
.local default name.  Whether to supress providing local mappings to
external queries could also be a simple configuration knob.

We need a extremely strong motivation to reinvent the wheel on
something as fundamental as name resolution.  I don't see that we have
any unmet requirement that can't be solved using DNS as the basis.  I
admit that we can't use any of the existing freely available DNS
server software (that I am aware of) because it does not do anything
useful in the absense of configuration and configuration is overly
complex for homenet use.

Curtis