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

Ted Lemon <mellon@fugue.com> Sun, 24 April 2016 03:04 UTC

Return-Path: <mellon@fugue.com>
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 38DFB12D199 for <homenet@ietfa.amsl.com>; Sat, 23 Apr 2016 20:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 GIYbbUn7wraJ for <homenet@ietfa.amsl.com>; Sat, 23 Apr 2016 20:04:11 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A94B12D0F5 for <homenet@ietf.org>; Sat, 23 Apr 2016 20:04:11 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id ys16so62116441lbb.3 for <homenet@ietf.org>; Sat, 23 Apr 2016 20:04:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AxCYPaqqS/57e4MA2FfIoxM8RgxZVAJ3La9mslt+z0Q=; b=rtvOIY1KG57poBQ/aBDBRqf9TDlaGUSEvgYQ5p8vZ8daGL9Iu3p0PyJcsvBA9vth5W z67KPIOw2sNgfjuI3hH13lpGIW547ObNzfOoP25/nC4jM3tWnVMlTsvziYCEl85G8SMw WaxgENZJV3HR2/6AKh7zdejEqD/+JAdwMA7ljVZ9am7HQ3zSGYytvkTfGVrY5lqE+/9a /DNmo4YDQq+TZGwriKXClUhhRh9lEZfF/zJ+Mn4gxwGLiNRVVhK85VfuwjZjXgahIKhE pYzzv9xgzxBEuALayydMAxf/HT16ZGX+MUiDpZ+EoPpqUgBayDXxtmsvdy5BHLUze2Xz XEZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AxCYPaqqS/57e4MA2FfIoxM8RgxZVAJ3La9mslt+z0Q=; b=gtnHYy4P8W3FloYPL494DzPdGNWqgq455eCinZVG28TYzspqj1+U2Y0Jes71cDf70E la0abjM6Zu6BC+BvVYeKnLecegjjd+U/VHttsm2fb93cA4gTHVYEqFWWoaEno/96z823 f1dZPKUpy0IMxzsY9aMgn9dXsiSJf0kspsT020yv7iXrlsYA97pJOWIqcvEs8oBbuDTP vEV/N16IhR2sCBB27jmZ1/S3J1wNTTKk7zbl4islYMvssHhm7YjghGlc1xZUR896RpF7 XrRUFjPLOixF93WCNoKEI0K9ahvb6yffN85ZgpYfRpVsC4WjV4ZJuH2Ulvu3g31HP0Zr hIiw==
X-Gm-Message-State: AOPr4FXoF3SR42iNbC2bcJOvpV8r1v3HsEzZaM8k9bBbhmcdF1T9/V3cMyNthP+9unzlSqYrGFI5fsbAy2LhXg==
X-Received: by 10.112.13.8 with SMTP id d8mr11458166lbc.110.1461467049404; Sat, 23 Apr 2016 20:04:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.213.19 with HTTP; Sat, 23 Apr 2016 20:03:29 -0700 (PDT)
X-Originating-IP: [71.233.41.235]
In-Reply-To: <87eg9wfctc.wl-jch@pps.univ-paris-diderot.fr>
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>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 23 Apr 2016 23:03:29 -0400
Message-ID: <CAPt1N1nq1CTMmQHFQXnaFY73SyRPKpWagiMVfrHODakbeT2Wxw@mail.gmail.com>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Content-Type: multipart/alternative; boundary=001a11c3b44e54bbe405313250ef
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/viEFMqv1ZREhnoK_JkdamMwgnzI>
Cc: homenet@ietf.org, Markus Stenberg <markus.stenberg@iki.fi>
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: Sun, 24 Apr 2016 03:04:13 -0000

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.   Just
2136 isn't enough, because there's no authentication scheme, and name
servers typically don't take updates from devices, nor is the default
domain on a typical home network actually even under the control of the
owner of that network.

The reason for doing mdns snooping is that we have no choice.   It's not a
great solution.   However, I believe it can be done in a way that is clean
and works.   It will not be stateless, although whether the state needs to
be persistent is an interesting question.  mDNS isn't actually entirely
stateless anyway, FWIW.

If you think this is a can of worms you'd rather not open, I can understand
that, but Stuart and I have had some pretty good conversations about this,
and I remain convinced that we can make it work, so I'd encourage you to
see what comes out of that process rather than assuming that the situation
is hopeless.

On Sat, Apr 23, 2016 at 1:35 PM, Juliusz Chroboczek <
jch@pps.univ-paris-diderot.fr>; wrote:

> >> Do you mean, (1) how is a DNS resolver advertised to clients, or
> >> (2) how clients are registered in DNS ?
> >>
> >> (1) is done by using the -N flag on the router advertising an external
> >> connection (-E).  This flag can be repeated multiple times.
>
> > hnetd grabs this automatically from wan-facing DHCP client,
>
> Yep.  Shncpd might learn to act as a DHCPv4 and DHCPv6-PD client at some
> point.  (But first implement IPv4 edge router election, which is one of
> the three missing features that I feel are necessary, security aside.)
>
> >> (2) is a host issue, so I believe it is better handled outside of
> shncpd,
> >> but I'm quite willing to be convinced otherwise.  (The obvious
> alternative
> >> would be to have shncpd update DNS when it gives out a DHCP lease, but
> >> that would mean giving up on stateless autoconf.)
>
> > Well, DHCPv4 is stateful anyway, and you could in theory bind state from
> > there as well (at least if you do IPv4).
>
> Yes.  I'm not sure how shncpd should update the state, though, since it
> doesn't act as a DNS resolver, it only passes the address of an existing
> DNS resolver to clients, and I don't want to bind it to any specific
> implementation of a DNS resolver.
>
> >> Markus, Steven, Ted?  What's the plan here?  Do we count on mDNS
> proxying,
> >> or should we be advertising an RFC 2136 server over HNCP?
>
> > I think the plan varies ;-)
>
> Yeah, that's what I gathered.
>
> > hnetd (and current HNCP + my expired autoconf draft) are based on the
> > idea of using mDNS _and/or stateful DHCPv4 and/or stateful DHCPv6 to
> > determine what’s on each link,
>
> Quoting Stephen:
>
>    I agree with you as well, initially odhcpd did only do RAs and
>    stateless DHCPv6 however the user community liked their stateful
>    (v4isms) all too much so I had to give in. ;)
>
>    -- https://github.com/sbyx/odhcpd/issues/55
>
> > Ted’s draft proposes either learn-from-mDNS (=proxy DNS-update) and/or
> > (manually/automatically configured client-sourced) DNS-update
> > scheme. I am worried about zone merging + conflict resolution, although
> > if it works out it sounds like a good solution.
>
> > (Zone merging + plain hybrid proxy is at least very problematic, if you
> > want hybrid proxies to remain stateless. I have looked at it and it is
> > neither pretty nor efficient.)
>
> I haven't looked at it, but my instinct would be to agree with you --
> proxying in the presence of merging sounds like a can of worms that we
> don't want to open.
>
> Do any of the Wise People on this list have opinions about RFC 2136?
>
> -- Juliusz
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>