Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback

Tom Pusateri <pusateri@bangj.com> Mon, 18 February 2019 13:04 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9B127AC2; Mon, 18 Feb 2019 05:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 33MxilIKOQCe; Mon, 18 Feb 2019 05:04:42 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EC71277CC; Mon, 18 Feb 2019 05:04:42 -0800 (PST)
Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 755B227CEF; Mon, 18 Feb 2019 08:04:41 -0500 (EST)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <27B3FC67-EE91-4D6D-B8AE-17A79348D147@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93CF4D7A-90D8-4E78-A6BA-4F0A81CD5447"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 18 Feb 2019 08:04:40 -0500
In-Reply-To: <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com>
Cc: dnssd <dnssd@ietf.org>
To: draft-ietf-rtcweb-mdns-ice-candidates.authors@ietf.org
References: <C069934A-C5ED-48CA-A857-AE457A3566D3@bangj.com> <68C82424-2406-4DAE-8EB7-59BB0AD78016@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/AxWq0ibYDvW9958br-iy288BVK8>
Subject: Re: [dnssd] draft-ietf-rtcweb-mdns-ice-candidates-02 feedback
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 13:04:45 -0000


> On Feb 17, 2019, at 5:30 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
> Thinking about this a little more, I would suggest splitting this into two documents. One that describes an mDNS alias name registration extension to RFC 6 762 and a second document that uses the first document to create unique RFC 4122 names for rtcweb.
> 

As I’ve thought about this overnight, I’m not convinced that extending mDNS for name aliases is even necessary. If you did, I would definitely want to know the response is not from the owner which means defining a new header bit or new OPT extension.

A simpler way to achieve this would be to just define a new service provided by the name mapper. The mapper can generate unique names for IP addresses as needed and limit their time and scope as it sees fit.

When another process needs to know if a unique .local name resolves to a local IP address, it can locate the name mapper using service discovery (PTR query for _ice-name-mapper._tcp.local, etc.), get the SRV record and ask the target directly.

Tom