Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 05 May 2016 12:00 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AA212D1BC for <homenet@ietfa.amsl.com>; Thu, 5 May 2016 05:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.516
X-Spam-Level:
X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn-yvTgx1zpR for <homenet@ietfa.amsl.com>; Thu, 5 May 2016 05:00:47 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0AF12D193 for <homenet@ietf.org>; Thu, 5 May 2016 05:00:44 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u45C0Up8029093; Thu, 5 May 2016 13:00:30 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u45C0Up8029093
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1462449630; bh=ZVt4jlm/07rAGknqbroNtBEa60I=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=wgfXRx1kW9jTng6sn0TWdtCKQJWefTGAJOG+glvIfv2W6WFYhNUEJEt3RGQJ++2bc n0R/iXUQgrexolDIyVor3kecWKSt9lRqo6OdHusFsJHD9G0KGcfVkjp1CqND548YOO 8K+2IU3vE+VxwVZkeOik1C9RJZVzin6IkMWGtIDI=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id s44D0U2391104686Jl ret-id none; Thu, 05 May 2016 13:00:30 +0100
Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:5d16:8598:2c35:8495] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u45C0KaG020553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 May 2016 13:00:20 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_F028E08E-3236-48CC-A6F8-FDED1688F63D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <CAPt1N1nN+ih8xpBV_-T_JaGtbBG6d5zYqW==tph8yN_UB34NNw@mail.gmail.com>
Date: Thu, 5 May 2016 13:00:20 +0100
Message-ID: <EMEW3|87dc38b1e390496e02166dafe2490d8as44D0U03tjc|ecs.soton.ac.uk|56DB4264-1769-443A-86F2-BB0BE0ED9693@ecs.soton.ac.uk>
References: <6E709688-414A-4AFB-AEAE-56BAE0469583@coote.org> <87oa93vz8e.wl-jch@pps.univ-paris-diderot.fr> <917CFE11-2386-4B0D-8A81-F87764AC09A4@coote.org> <87lh47vtpe.wl-jch@pps.univ-paris-diderot.fr> <02CF43FB-CF81-4C0C-84E1-A8DFB27B3F8C@coote.org> <87lh44fff7.wl-jch@pps.univ-paris-diderot.fr> <48A9C52C-85BC-4123-A3ED-FB269AD03126@iki.fi> <87eg9wfctc.wl-jch@pps.univ-paris-diderot.fr> <CAPt1N1nq1CTMmQHFQXnaFY73SyRPKpWagiMVfrHODakbeT2Wxw@mail.gmail.com> <87a8kj3r7p.wl-jch@pps.univ-paris-diderot.fr> <CAPt1N1nN+ih8xpBV_-T_JaGtbBG6d5zYqW==tph8yN_UB34NNw@mail.gmail.com> <56DB4264-1769-443A-86F2-BB0BE0ED9693@ecs.soton.ac.uk>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3124)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=s44D0U239110468600; tid=s44D0U2391104686Jl; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: u45C0Up8029093
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/vFdiswZyhQdd03q5QdOWGDiFF4c>
Cc: homenet@ietf.org, Markus Stenberg <markus.stenberg@iki.fi>, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Subject: Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2016 12:00:51 -0000

> On 25 Apr 2016, at 03:39, Ted Lemon <mellon@fugue.com>; wrote:
> 
> On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr <mailto:jch@pps.univ-paris-diderot.fr>> wrote:
> > Juliusz, the problem is that existing home network devices that do
> > DNS-based service discovery do not support DNS update. They could, but
> > they don't, because we didn't define an easy way for them to do it.
> 
> I'd be grateful if you could expand on that.  Why can't we define a way
> for clients to do DDNS?
> 
> We can and should.   The problem is that we won't see that code ship in new devices anytime soon, so we still have to make mDNS work.

And this is why the dnssd WG is focused on making mDNS work on multi-subnet networks.

But Ted has raised the question of DNS Update there, and we agreed in BA that we’d accept a draft on issues around coexistence of mDNS and DNS Update.

> > Just 2136 isn't enfough, because there's no authentication scheme,
> 
> I don't understand this argument.  How is non-secured DDNS any less secure
> than mDNS?  What am I missing?
> 
> This is an implementation issue, not a security issue--sorry for not making that clear.   In order to preserve the same security characteristics that mDNS has, we have to ensure that the update actually originated on the local link, which requires a different sort of listener than is present in a typical DNS server.   And existing DNS servers typically don't have any way to support unauthenticated updates on a first-come, first-served basis, so if you allow unauthenticated updates, you don't have any way to avoid collisions.   Otherwise you are correct.   The answer is to write a document that describes how to do that, and if you read the homenet naming arch document, you can see that I actually sketched out a solution there, which I expect to go in a different document, likely in a different working group.

There are many worms in that can :)

> Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
> actually of a divided mind here -- I rather like distributed solutions
> (hence prefer mDNS to DDNS) but dislike proxying.  Part of me just wishes
> we'd mandate site-local multicast and do mDNS over that
> 
> The problem with site-local multicast for mDNS is that multicast isn't a great solution even on the local wire when that wire is wireless.    And, you have to do modify the client anyway.

Indeed; this was discussed early on in the dnssd WG, and not considered for those reasons. 

> Furthermore, if you consider the mdns hybrid proxy stateless, then you can have a DNS server that is roughly that stateless too.   I think it provides better service continuity if you are willing to retain some state, but everything will still work even if you don't, just as the hybrid proxy does.

Agreed.

Tim

> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet