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

[Daniel Migault <[e-mail]>]

Hi Andrew,

Thank you for your comments, we are considering them for the next version.
I am answering in the text.

Mostly, I am worried that this proposal is a cure worse than the

> disease.  I've read the draft several times, and I just don't get why
> it isn't better to put all this DNS data out in a public DNS server
> somewhere, and have everything (including the nodes inside the homenet
> boundary) query that.


The architecture document recommends not to outsource everything in a
server outside the homenet.


3.7.3 <http://tools.ietf.org/html/draft-ietf-homenet-arch-06#section-3.7.3>.
 Name spaces

   It is desirable that only one name space is in use in the homenet,
   and that this name space is served authoritatively by a server in the
   homenet, most likely resident on the CER.


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


3.7.5 <http://tools.ietf.org/html/draft-ietf-homenet-arch-06#section-3.7.5>.
 Independent operation

   Name resolution and service discovery for reachable devices must
   continue to function if the local network is disconnected from the
   global Internet, e.g. a local media server should still be available
   even if the Internet link is down for an extended period.




> If you want to reduce traffic, put a DNS
> cacheing resolver on the CPE.


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. Of course the diagram should be
considered as a functional diagram. We will clarify this in the next
version thanks for the remark.



>  Use a simple-minded http-based
> injection protocol for DNS data that the CPE can use (we have several
> of those deployed, although none is an IETF protocol).
>

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.

Then filling may not be appropriated, since we need to properly manage the
Public Server with appropriated data (updating information  checking
versions...). These requirements are addressed by IETF defined protocols,
benefit from multiple implementations and a lot of experience. We do not
see any reasons to do something different. On the other hand, we may also
provide some alternatives, for specific use cases. We will do that in the
next version, feel free to send these use cases on the Mailing list.


The proposal as it stands includes support for different views; for
> mixed-mode authoritative and recursive services in the same resolver,
> something we regularly say is a bad thing;


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.

However you are right that in some case the Authoritative Server will be
hosted by the CPE. We still believe it is more realistic to host the
Resolving Server and the Authoritative Server on a same device, than to ask
the End User to have an additional box for their Authoritative Server. Port
binding, firewall rules on that boxe probably match the BCP. The main
advantage of having this configured in the box is that most of the
misconfiguration issues may be avoided.


and three options for
> securing zone transfers, one of which we heard in mdnsext is the
> barrier to adoption of unicast DNS DNS-SD.  Many of these tricks --
> views in particular -- work only most of the time when careful
> administrators set the whole thing up, and so I'm worried that we're
> not going to be able to build automatic tools that allow this all to
> work completely reliably, _especially_ when inside the homenet most of
> the time people will actually get mDNS answers anyway and so there'll
> be a mismatch between the name spaces.  It's mostly the complexity of
> all of this that troubles me.
>

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


>
> How much of it is necessary?
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> [e-mail]
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Daniel Migault
Orange Labs -- Security
[phone]