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

Markus Stenberg <> Sun, 24 April 2016 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE0F312D109 for <>; Sat, 23 Apr 2016 23:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L-zqZ8b6olH0 for <>; Sat, 23 Apr 2016 23:18:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3678912D0E0 for <>; Sat, 23 Apr 2016 23:18:46 -0700 (PDT)
RazorGate-KAS: Status: not_detected
RazorGate-KAS: Rate: 0
RazorGate-KAS: Envelope from:
RazorGate-KAS: Version: 5.5.3
RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29
RazorGate-KAS: Lua profiles 69136 [Nov 12 2014]
RazorGate-KAS: Method: none
Received: from poro.lan ( by ( (authenticated as stenma-47) id 5702409101A83249; Sun, 24 Apr 2016 09:18:43 +0300
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Markus Stenberg <>
In-Reply-To: <>
Date: Sun, 24 Apr 2016 09:18:42 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:, Juliusz Chroboczek <>
Subject: Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Apr 2016 06:18:51 -0000

On 24.4.2016, at 6.03, Ted Lemon <> 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.   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.

mDNS has only locally published state (and non-local state caching which can be ignored if you do not care about query efficiency but you really should), and as hybrid proxies do not publish local state, they can be implemented statelessly. 
For home network case, probably just the DNS-SD legacy browse (‘flat names, hide domain’ scheme) with per-link hybrid proxy zones would work fine; as Stuart said, mDNS state caching (if implemented by the hybrid proxies) would make it relatively efficient (in terms of multicast; there would still be N unicasts per lookup where N is the number of links=zones, which would not be cached, but 0 multicasts if the mDNS caches on the hybrid proxies are up to date). As added bonus, no bogus domains would be shown to users, and you would just have two ‘printer’s if you were silly enough not to give them better names and they lived on different links.

> 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.

I am a Finn, we are pessimistic by default. But I am looking forward to what you come up with ;) 

If we want to get really pessimistic about this whole thing, though, it seems to me that the market is going for ‘cloudy’ solutions to anything, where there is no p2p communication _even on the same network_ but instead some cloud server intermediary, which when unavailable/expired/having a bad hair day, means you are simply not doing what you wanted to do.