[homenet] homenet "no host changes" assumption and DNS

"STARK, BARBARA H" <bs7652@att.com> Fri, 18 August 2017 13:21 UTC

Return-Path: <bs7652@att.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 8346C13240D for <homenet@ietfa.amsl.com>; Fri, 18 Aug 2017 06:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.401
X-Spam-Level:
X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 6mHu7vzUHjVB for <homenet@ietfa.amsl.com>; Fri, 18 Aug 2017 06:21:29 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967351323C0 for <homenet@ietf.org>; Fri, 18 Aug 2017 06:21:28 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7IDFwZq017012 for <homenet@ietf.org>; Fri, 18 Aug 2017 09:21:25 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2cds4xc96f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <homenet@ietf.org>; Fri, 18 Aug 2017 09:21:25 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7IDLOjq007495 for <homenet@ietf.org>; Fri, 18 Aug 2017 09:21:24 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7IDLIGR007407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <homenet@ietf.org>; Fri, 18 Aug 2017 09:21:20 -0400
Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor) for <homenet@ietf.org>; Fri, 18 Aug 2017 13:21:07 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Fri, 18 Aug 2017 09:21:07 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "homenet@ietf.org" <homenet@ietf.org>
Thread-Topic: homenet "no host changes" assumption and DNS
Thread-Index: AdMYFPIEV1k/IIYrQxOO94GV5djuUw==
Date: Fri, 18 Aug 2017 13:21:06 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.210.141]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708180212
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/B1H1Wk-sUiG5-Js2Dh_VTeLqB8I>
Subject: [homenet] homenet "no host changes" assumption and DNS
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 18 Aug 2017 13:21:39 -0000

No hat.
I'm proposing something radical here. Let the tomatoes fly.
I'd like to question whether we really need to maintain the "no changes to the host" assumption when it comes to architecting homenet DNS.
Currently, there is no host that expects to use .home.arpa (or any other domain) inside the premises. There is no host that expects a general-purpose in-home domain name system to work or be present. The widest use of in-home domains is the way ISPs use domains like ".home". To the best of my knowledge, they use those for access to the ISP-supplied router's HTTP-served content. Nothing else. The "no host changes" tenet was primarily about not breaking existing host functionality. A fully functional in-home domain name system is not something any legacy host has expectations or functionality for. As long as we don't break usage of Internet DNS, there should not be any requirement or mandate that we have to make in-home DNS work for legacy hosts.

If we got rid of the "no changes to host" tenet (for hosts that can make use of the home naming architecture), that would give us much more freedom to create an in-home DNS architecture without a dependency on homenet routers implementing the DNS Proxy kludge. Or any other kludge. It would let us create an architecture that would finally start to move us away from DNS Proxy and other methods that intercept DNS queries to make supposedly "intelligent" decisions on behalf of stupid hosts. And we would not be further entrenching use of these DNS intercept functions.

I would like to require the hosts that want to make use of the new homenet naming architecture responsible for understanding the different provisioning domains and simultaneously launching queries to the advertised (or internally configured) DNS servers for each provisioning domain. 

The host that gets multiple DNS responses needs to be responsible for making the decision that's right for it. In the case of multiple Internet connections: if the application needs high bandwidth and low loss but latency isn't important (e.g., streaming video), then maybe it picks the high bandwidth high latency low loss connection. If it needs low latency but not much bandwidth (e.g., VoIP), then maybe it picks the low bandwidth low latency connection. The CE router should not be making this decision (which DNS response to supply to the host) on behalf of apps it knows nothing about.

Make the home domain a different provisioning domain, and insist that hosts wanting to make use of domain names in the home domain must understand provisioning domains and how to use and interact with them. The home domain DNS server can be advertised by mDNS or other means.

I truly believe we need to start moving towards providing hosts with the info they need to make their own decisions. DNS Proxy mandates (or other DNS intercept mechanisms) are antithetical to this. 
Barbara