Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01

[Andrew Sullivan <[e-mail]>]

On Wed, Nov 07, 2012 at 05:33:45PM -0500, Daniel Migault wrote:
> The architecture document recommends not to outsource everything in a
> server outside the homenet.

Well, yes, but note also that it says that you want only one name
space.  This requirement is _certainly_ going to be violated in the
medium term, because everyone is using mDNS and there's no evidence
that anyone is ready to back off their plans (the zigbee guys are
cleaving to it).  

The draft as it stands seems to imagine that what people will use is
one namespace, and it'll be DNS.  Ten years ago, I might have said,
"Could happen."  Today, it's impossible.  We are going to have two
namespaces here.  (Yes, a complete review of -arch- is on my TODO.
After today's meeting, at least I've moved it higher in the list.)

> This is actually the only way to provide the Service Naming resolution in
> case the connectivity of the homenet to the Internet is down.

That is a good point.  It might be emphasised more strongly in the
draft, unless I'm just missing it (which is possible).

> The goal is not to reduce the traffic but to avoid exposing the CPE to
> resource exhaustion by hosting a DNS service on the CPE. However caching
> the Resolver may be in some case be a way to replace the what we designated
> as the Homenet Authoritative Server. 

Yeah, that's pretty much what I had in mind.  But such a cache
wouldn't solve your "disconnected operation" problem.

> If I understand correctly, you use an http-base protocol to fill the CPE
> with the appropriated DNS data. In fact we are doing the reverse. The CPE
> has the data and injects the DNS Data to the Public Server, so that it can
> properly perform the DNS authoritative service.

Actually, Dyn (for instance -- full disclosure, they paid for my trip
here) takes updates from many end points via an http-based API.  This
is for information that goes into global DNS servers.  Yes, we could
do this with Dynamic Update, but that involves a more complicated
security model that is poorly understood by the sort of developers who
often work on the end point code.  Telling them, "use TLS and HTTP"
allows them to pick up libraries that we are reasonably confident are
well-developed as opposed to writing code to do TSIG.

> In the most common case, the DNS zone hosted by the CPE is only requested
> by the Resolver. The diagram should be considered as a functional diagram.
> In most common cases, the Authoritative Server will be more like a file or
> cached in the resolving server. Thanks for the remark, we will clarify this
> in the next version.

Well, it's like a file that is interpreted by a server that can send
DNS responses.  I agree the uses aren't manifold, but it's still a
mixed authoritative/recursive server as far as the client is
concerned.  Maybe we've decided that for this case, that's good
enough, but since it's at odds with some experience we've had with the
DNS more generally, it's worth noting it.

> Views are optional. Can you provide specific scenarios we need to address?

My personal view is that views are hateful, but many people seem to think
it's important to hide names when one isn't authorized to use them.
In any case, you're undoubtedly going to need views wherever there's a
NAT and v4.

A


-- 
Andrew Sullivan
[e-mail]