From nobody Mon Jan 11 16:33:44 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7A21ACC83; Mon, 11 Jan 2016 16:33:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112003341.5501.86209.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 16:33:41 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-04.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 00:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-04.txt Pages : 23 Date : 2016-01-11 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 17 14:59:12 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279DD1A90A3 for ; Sun, 17 Jan 2016 14:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EWkab0S-i2Dc for ; Sun, 17 Jan 2016 14:59:08 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F491A90A2 for ; Sun, 17 Jan 2016 14:59:08 -0800 (PST) Received: from [172.16.25.123] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4DEC4FA89 for ; Sun, 17 Jan 2016 17:55:50 -0500 (EST) From: Tom Pusateri X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_F53508F4-88A8-4DFD-844D-4F424CDFBFCA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 17 Jan 2016 17:59:05 -0500 Message-Id: <93893951-3510-4910-A69F-AD189E6E8FA6@bangj.com> To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-hybrid-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 22:59:11 -0000 --Apple-Mail=_F53508F4-88A8-4DFD-844D-4F424CDFBFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Overall, the -02 version is very good. Section 4.5.1 on DNS TTL limiting = is very helpful for implementation. Also, the four modes of responding = listed in section 4.6 on Answer Aggregation is a tremendous addition. = Thanks for these. In an earlier note to the mailing list, I reviewed an earlier version of = this draft. https://mailarchive.ietf.org/arch/msg/dnssd/a1eAnObKtaOjg7ju6-aOEZyRWfg Some of the comments have been addressed and some have not. For = Stuart=E2=80=99s convenience, I am listing all of the previous comments = that still apply and adding some new ones so there is no need to go back = and try to match old section numbers. 2. (3rd paragraph) - There is a pointer to [802.5] with no matching = reference. Add = http://xml2rfc.ietf.org/public/rfc/bibxml2/reference.IEEE.802-5.1995.xml (new) 4.2 Domain Enumeration - I think using the term =E2=80=9Chome=E2=80=9D= domain is confusing with regards to homenet and a different term should = be used. (new) 4.2.2 (3rd paragraph) - the use of =E2=80=9Cconfiguration data=E2=80= =9D is ambiguous. I would like to see this be more specific. 4.3 Title =E2=80=9CLDH" - The acronym LDH (Letter, Digit, Hyphen) is not = defined or referenced anywhere. A reference to Section 2.2 of RFC 5890 = should be included. (new) 4.3 (5th paragraph) - =E2=80=9Ca Hybrid proxy should support = having separate subdomains delegated to it=E2=80=9D. This should say for = the same link since proxies can already have separate subdomains across = multiple links. 4.3, 4.4 - The example IP addresses should use documentation IPv4 = address ranges as specified in RFC 5737. 4.4 (5th paragraph) - "(In the Apple "/usr/include/dns_sd.h" APIs, using = ForceMulticast indicates that the DNSServiceQueryRecord() call should = perform the query using Multicast DNS.)=E2=80=9D - I don=E2=80=99t think = this implementation detail is necessary. 4.5.2 - Since hybrid proxies can never know all of the possible records = in the subdomain, it is not possible to build NSEC next record = relations. Therefore, all NSEC records learned over mDNS (typically in = the Additional Section) should be filtered in unicast DNS responses sent = by the hybrid proxy. (new) 5. DNS SOA - I would like to see an introductory paragraph = explaining the hybrid proxy should respond to SOA record requests for = each subdomain assigned to the hybrid proxy. 8.1 The hybrid proxy could also only provide sensitive records to = authenticated users. But this is a general DNS problem and not a problem = specific to the hybrid proxy. A reference to the work in DPRIVE that = outlines DNS privacy issues might be appropriate (now published as RFC = 7626). Thanks, Tom --Apple-Mail=_F53508F4-88A8-4DFD-844D-4F424CDFBFCA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJWnBy6AAoJEPk0GMVmUuYMrvUH+QFhSn7uXoCVpF7F6M1Fqb0J qC/J3DOhwEcbm5EiABeJG2klyR0cXV1wcVYgUgrIlNJoPQPoB5zfMPnpQ1yuYyXO c9GKDJ8NNtOnaweRLy63VkMlMFXmYWQGjau8LgDokAhnECMkgP0t26M74M0VXbym PNU4ndPPvXDVWXYpNRxJzJ5LOTXZCjca2y3RfY2AR0uABBP9KV14wpH39+CJhSyp 1e0ZBQYrGSYiKfrctVJF3uTAkxmpGO4HzHfn2RdhnnTcDDYOZVye6ZEQ3ODaDGBN x/BEwgWUKOx1WOcmimLac56UPo/McAVZCMlPYjkrGM/G7o1Z7OtzB+59mPoKyXo= =/8gB -----END PGP SIGNATURE----- --Apple-Mail=_F53508F4-88A8-4DFD-844D-4F424CDFBFCA-- From nobody Thu Jan 28 09:24:08 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16471A8AEA for ; Thu, 28 Jan 2016 09:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GMeAWZCRGSFy for ; Thu, 28 Jan 2016 09:24:05 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 E6A3A1A8AE0 for ; Thu, 28 Jan 2016 09:24:04 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id e32so44838120qgf.3 for ; Thu, 28 Jan 2016 09:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=61DR7MWyER12FX7pxJaYwZZszNos1FjUeHnaOi/tgIM=; b=UM0N7W+it1vXtGXg01u68mMEV/3jawkam81SblTuu5AUYGZlHmxaja3y4xVL7Cpb5H I+n7+Ctx0bG7iM0bkBo+QNdIGoHAVb7RtyG3IesCRbFp9U5+iH7RC5FeavFa4UeJXuzs qTXVLWBd5kfXV4uU6uP3VPhJhXsvWAWhVsbumyBxPjB4J+elbJ0N4gEnwGm3HWy88g9l kwoyoPIbLgU9gwA6T8/tOHbzvLZ2vOLy9RoG1ohv0IuEP7O6nFAAPyAY9C+pJ2Dky7vb auyYYogBmCP4booz+nvQMDYpTi0Jx2Z+vi4ZZGQkmIo33V6cn2koRv3r5eAxC0iiuzAW QcFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=61DR7MWyER12FX7pxJaYwZZszNos1FjUeHnaOi/tgIM=; b=H6VA+rT5blxjeru/zrUFlbz2JfPYAfttimpcRVWKt7/VODFO8nMQQrMz8KTbtOEQ2F YeifOoGO5aITXMIBFRSTrHBL60uhuX9xXfKKtUKg/XyYtiISO6F/kIqsogGlATlWVrPy byN1xJgRiFf+7COfjdoZ+XcebL+8KTqndyduQ8jeS6jFvRf9X+onyHpj6pm334G/uhAT 1qm2azZnD3qt47rMsrkLn6XuAdaSYg36Ygd4qJqH0qMMyYD52zrb1mGZS4eTe0Wc618Z mJM5dm8lf8wcaM4plG4ffTSEjRZ7fVUJdAVoI+S2I6hGqVgFagW9MSsRVNsxJRK3V3vS 2UkA== X-Gm-Message-State: AG10YORVwwGCw9WM88eocJYUjJIjwTtK0GQEjQgkm0slmVLir/p1ghJS+pRoi+c8uHITZaTh82Llm48L/LDbFw== X-Received: by 10.140.94.68 with SMTP id f62mr5143514qge.0.1454001844077; Thu, 28 Jan 2016 09:24:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 28 Jan 2016 09:23:44 -0800 (PST) From: Ted Hardie Date: Thu, 28 Jan 2016 09:23:44 -0800 Message-ID: To: dnssd@ietf.org, Andrew Sullivan , Suzanne Woolf Content-Type: multipart/alternative; boundary=001a11394c9e6b4a5a052a682f5f Archived-At: Subject: [dnssd] ARCING BoF and mailing list X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 17:24:06 -0000 --001a11394c9e6b4a5a052a682f5f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, Andrew Sullivan, Suzanne Woolf and I have put a request in for a BoF at IETF 95 (arcing ) that is trying to take a slightly different squint at how to manage alternative resolution contexts like that of mDNS, .onion, or similar. We're trying to look beyond recent issues about RFC 6761 and special use name =E2=80=8B to see if there are different architectural approaches to the gen= eral problem. =E2=80=8B There's a stab at a problem statement draft available, building off of work that's already been done in DNSOP and other places. There is also a mailing list set up for early discussion ( arcing@ietf.org), and we'd appreciate anyone interested in the topic joining the discussion there. Apologies if you get multiple copies; it must mean we *really* want you to join. thanks, Ted, Andrew, Suzanne --001a11394c9e6b4a5a052a682f5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Andrew Sullivan, Suzanne Woolf and I have= put a request in for a BoF at IETF 95 (arcing) that is trying to take a slightly different squint at how to manage=20 alternative resolution contexts like that of mDNS, .onion, or similar.=C2= =A0=20 We're trying to look beyond recent issues about RFC 6761 and special us= e name
=E2=80=8B to see if there are different architec= tural approaches to the general problem.

=E2=80=8B
There's = a stab at a problem statement draft available, building off of work that's already been done in DNSOP and= =20 other places.=C2=A0 There is also a mailing list set up for early discussio= n (arcing@ietf.org= ), and we'd appreciate anyone interested in the topic joining the discu= ssion there.

Apologies if you get multiple copies; it must mean we *really* wa= nt you to join.

thanks,

Ted, Andrew, Suzanne=C2=A0
--001a11394c9e6b4a5a052a682f5f-- From nobody Fri Jan 29 17:52:20 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 861801B2CCE; Fri, 29 Jan 2016 17:52:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160130015217.31607.19391.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 17:52:17 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-05.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 01:52:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-05.txt Pages : 24 Date : 2016-01-29 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 29 18:25:09 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C31B2E2E; Fri, 29 Jan 2016 18:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bdGp3CCp0KUM; Fri, 29 Jan 2016 18:25:05 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 F1ABA1B2E30; Fri, 29 Jan 2016 18:25:04 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id yy13so50272907pab.3; Fri, 29 Jan 2016 18:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=jkCfmcrpv7NIX6P5YTaX+5eGKszm/A+D2ZFQtOmlmK4BLsLeT82I3T5E2UbZfEu49/ UOybCEZK6T6pdieF18UpacCvEYUfMzZ3SQO04J2p/kniaaERJ1jnmEtz/OUgRvTbDXiF nMxt4tOMtlhnV7k38jKiXCiB8wHoj8UzVMPnzarsx0Ce/5m0PkMEJiaLBYn5rS5Kq6Ne itjgElsCwwCKo7e6/QL5LLmmG54q7rwbAGcY9rylhUcv25mjGpgEK/Kr2Hx/4Et1x6vQ 7R1WufoyZ/oUNgLfdr9lvttJvwjVO/0UJugjdrWcdkRqokPJBUbdc6iaF9bAynYRnWA/ cGIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:cc:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=AG0fFVUK4Rt2GfR3v4Lil40IQ6Utu9waMQcGkeEh+EXUATN1dsp7K13wtxbW3YEPDs A9C0q8sOLxH7wzSinfA9wz+Ayua+WbHzzFrkZnr1O2eiURqCMacwnoABQjf/duOchHhS kzt4PEY+brxQSxkXruLw+ccHdqDC4cBhvZUGrw+651wIQY/NeMcF/6hk7u13axPeRPA4 tZbc4iXJsNzXLnogL24wbDM2cagWc3fL43F2ySAulmi4Zaq9jMe+Y6U9ygiQx2KxcvWB b/15entl47lXTdJDZR9HArScrSRDjsq3ufOIoaIoF9CyCuiM7sKCpZHtIXP91i7+Lka5 kFBQ== X-Gm-Message-State: AG10YOQ6ijxdMrCBX0EdjdXWTnLhW4VfcccDbz7gH6Fxr+jYA/emXfZC4qd/oaw81+mvWQ== X-Received: by 10.67.6.67 with SMTP id cs3mr18591125pad.143.1454120704663; Fri, 29 Jan 2016 18:25:04 -0800 (PST) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id 76sm14145121pft.44.2016.01.29.18.25.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 18:25:04 -0800 (PST) From: Douglas Otis X-Enigmail-Draft-Status: N1110 To: "arcing@ietf.org" Message-ID: <56AC1F60.6060803@gmail.com> Date: Fri, 29 Jan 2016 18:26:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Ray Bellis , Andrew Sullivan , ietf dnssd , mark@townsley.net, suzworldwide@gmail.com, Warren Kumari Subject: [dnssd] ARCING BoF and mailing list X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 02:25:07 -0000 Dear Ted, https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02 https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf ,-- Lacking clear RFC 1918-like guidance directing operators to DNS namespaces safe for internal use, several such namespaces have been “appropriated” for this purpose over the years. While the etiology is subtly different, the .corp and .home TLDs are clear outliers in this respect; the use of .corp and .home for internal namespaces/networks is so overwhelming that the inertia created by such a large “installed base” and prevalent use is not likely reversible. We also note that RFC 6762 suggests that .corp and .home are safe for use on internal networks. '-- Reservation of Special-Use Domain Names will not circumvent normal domain name registration processes. Reservation as a Special-Use Name can however ensure it is NOT part of the DNS global namespace and returns NXDOMAIN. In the case of .corp or .home, a responsible agency is irrelevant due to conventions established by those meeting obvious necessities. Registering a domain should not be considered a necessary expense for resolving hosts contained in homenet realms. A home network may consist of multiple links interconnected using IP-layer routing rather than link-layer bridging where multicast might be impractical or poorly supported. Homenet routers should not forward link-local IPv6 packets to exclude traffic forwarded from the global Internet and may not forward some multicast traffic (especially that of non-diffused mDNS). A Special-Use Domain Name can anchor DNS-SD resources without being mistaken for an organizational domain. Otherwise devices made by many vendors are likely to make use of non-registered names nevertheless. Adopting a Special-Use Domain Name better ensures against future name collisions and resulting confusion that might otherwise occur. The URI domain is normally assessed from a security standpoint and used to illicit user feedback of potential threats where changing the URI form would be counter productive since this would require needless widespread change. Special-Use Domain Names of Peer-to-Peer Name Systems GNU Name System (GNS), for example, defines a decentralized and censorship-resistant overlay able to operate within mesh network topology as a bootstrap replacement. Special zone relative names based on a distributed hash offer DNS-free access for Friend-to-Friend networks. Relative names end in '.+' which indicates names resolved relative to the current local authoritative zone. Replacing the '.+' with the delegation chain to the authoritative zone produces a valid GNS name. Swapping .home for .gnu reduces the burden seen at root servers, and offers interesting techniques for handling local name space that can be differentiated by GNS specific Resource Records. Perhaps an I-D should be written to further extend the potential use of a DNS overlay and how to make its use locally safe. Perhaps use of GNS Resource records as an extension could eliminate a need for the resources and administration otherwise necessary to support Internet accessed DNS just to establish local names not published below the .local TLD. Currently there is no site-local scope naming conventions available and this should be changed without impacting URI conventions where examination of the entire name is most often used to assess any need for caution. Regards, Douglas Otis