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

["Griffiths, Chris" <[e-mail]>]

On Nov 7, 2012, at 5:33 PM, Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:


 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 way I read this was to use something similar to the several free / commercial ASP services to publish to northbound public DNS platforms via HTTP (I assume Dyn and others fall into this bucket).  I don't disagree with this approach currently, but am curious why we wouldn't simply leverage the DNS protocol to perform these actions.  Either of these components could be primed to the Homenet gateway via configuration and/or automated.  That being said, would providing both options (DNS or HTTP) meet your thoughts here?  Certainly something we could add to the next version of the draft and I don't have a preference either way.



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.

I think something like mDNS and DNS-SD are an alternative to this approach.  I know Stuart Cheshire and team have wide area bonjour working quite nicely and could certainly fill this role and remove some complexity for design. I am curious if the proposed work in MDNSEXT might help with this.


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?


Agreed on multiple views, and curious how we can leverage mDNS and other service discovery mechanisms to generate and publish northbound.  Something we certainly want to update the next draft with.