Dear colleagues, On Fri, Sep 19, 2014 at 12:16:30AM -0700, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Home Networking Working Group of the IETF. > > Title : Outsourcing Home Network Authoritative Naming > Service > Authors : Daniel Migault > Wouter Cloetens > Chris Griffiths > Ralf Weber > Filename : draft-ietf-homenet-front-end-naming-delegation-00.txt
I have read this draft. I have a few comments. First, it's worth noting that the current specification means that DNS queries inside the homenet apparently rely on the availability of the Public Authoritative Servers. This is contrary to widely deployed practice, where gateways often answer for things inside the network. I'm not opposed to this in principle, but it does mean additional latency inside the homenet for certain kinds of operations, and it makes the resolution of names inside the homenet dependent on a service not subject to the homenet's administration -- one that will doubtless come under DoS, if experience in the rest of the DNS is any guide. Of course, it _has_ to be this way, because the document continues to recommend that signing happen outside the CPE, and therefore the CPE can't respond with signed records. Even if signing did happen on the CPE, there'd be a problem in that the CPE zone and the public zone will inevitably be different in the case of any NAT. (I know, we're all going to use v6 for this. And I agree, but we can't actually specify something guaranteed to break in the case of a v4 NAT.) But now I wonder how this is going to work in practice, because there are probably going to be some homenet nodes that one does not want to have published on the global Internet. Presumably those names one will want to access inside the homenet anyway. I suppose we could say "use only link-local resolution for those cases", though that of course restricts us to a single local link and I thought part of what was driving us was a desire not to have that restriction. Otherwise, the CPE has to be a DNS server for some but not all names inside the homenet, and a forwarder for the rest of them. That seems a little complicated. Since there are not different views, and since the CPE is not listed in the NS set for the zone, the CPE will never get queried unless it answers authoritatively without listing itself in the NS set; I suppose that's another way to do this, but if that's the plan then the document needs to be clear about it somewhere (if it's there, I'm sorry to have missed it. Perhaps it needs to be stated more plainly in that case). The recommendation not to use split-brain is clear in section 7, but the reasoning is opaque. If the CPE is never going to be queried, then the reasoning in 6.1 # 1 "pro-cpe-signing" doesn't make sense. The CPE doesn't actually respond to queries, so who cares if it has an equivalent zone? Similarly, reason 6.1 # 3 "anti-cpe-signing" seems a little strained -- don't you have the same problem if you change ISPs? As a nit, in the SOA description in section 4.2, the SOA Minimum field was respecified in RFC 2308, so that should be the reference. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
