Last Call comments on draft-ietf-dnsop-as112-dname-04
Ted Hardie <ted.ietf@gmail.com> Thu, 02 October 2014 17:31 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BE1A8952 for <ietf@ietfa.amsl.com>; Thu, 2 Oct 2014 10:31:35 -0700 (PDT)
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 sYAutUfzbbqC for <ietf@ietfa.amsl.com>; Thu, 2 Oct 2014 10:31:31 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35EC1A8A6D for <ietf@ietf.org>; Thu, 2 Oct 2014 10:31:31 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so2416637igc.0 for <ietf@ietf.org>; Thu, 02 Oct 2014 10:31:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pte9/bfkto9v7ZXQ28fI9toDo0gwFEYxQ5do8Jz/TJI=; b=cUFm1yseXhNxO9iWmjSTL6PurDGPLaYsBcRwbDJ7egkhaOmCcL99uE+ZSdcwA030Yu rCkQRI/0w0wvhiDu8+K7yF2xBDwuI3+tDu6zH5yFbn9Cccfe23LnfRm5MXK8hwrI31e2 EY8gtr1bQO03b2rgPw++5Z0mlKCqlgpCwhSRuaDPWhrDKVxv+0XyRANgyodOLbc7Edls +fFQx9jUrKfYNqVuOrsqRzw6H46xuLnyF8bbCcZKDX0CkR4P9agzGs03cwnX/17fcR2r xmhMnZf2VDH9gngL9ZdliYzVg0rDX3HyTCykwAw5gwLhIeM9ZgWXDkR334bkphtjgzQV njWA==
MIME-Version: 1.0
X-Received: by 10.42.236.19 with SMTP id ki19mr6923310icb.18.1412271091109; Thu, 02 Oct 2014 10:31:31 -0700 (PDT)
Received: by 10.43.3.4 with HTTP; Thu, 2 Oct 2014 10:31:31 -0700 (PDT)
Date: Thu, 02 Oct 2014 10:31:31 -0700
Message-ID: <CA+9kkMBQsoCNxNFe-zvzNPLiPEOi0dMEG_7OCOF5TW4nK5u5YA@mail.gmail.com>
Subject: Last Call comments on draft-ietf-dnsop-as112-dname-04
From: Ted Hardie <ted.ietf@gmail.com>
To: IETF <ietf@ietf.org>, draft-ietf-dnsop-as112-dname.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="20cf302446adb655ad050473fc33"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/iFOyX5kotECYF1tpqHXgl8bExz4
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Oct 2014 17:31:35 -0000
Thanks for the additional opportunity to comment on this draft. I believe that the abstract does not cover the change in scope of the AS112 service made by introducing this new mechanism. The original scope of the AS112 service was for reverse lookups that had no globally unique mapping (RFC 1918, link-local, etc.). That's the scope that the abstract mostly covers. This mechanism, however, changes the scope of the service to providing an NXDOMAIN to *any domain name DNAME'd to it* (Forward tree, reverse tree, anywhere, really). As the document puts it later: This approach has the advantage that query traffic for arbitrary parts of the namespace can be directed to AS112 servers without those servers having to be reconfigured every time a zone is added or removed. There is additional language which notes that the base intent is still related to zone of local significance: "Since additional zones of definitively local significance are known to exist, this presents a problem. " from the abstract. The context in the abstract, though, is this: In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. That implies a scope (private-use addresses), but the mechanism is essentially unscoped. I think the abstract should be changed to highlight this, since this is likely the major change others will see from this deployment. A set of examples of the non-reverse zones of local significance would also be useful. Given this change in scope, I also think the draft needs some additional language in both the security considerations section and section 6. The security considerations section currently has only this: This document presents no known additional security concerns to the Internet. For security considerations relating to AS112 service in general, see [RFC6304bis]. This assumes that the reader is familiar with cache poisoning attacks and the scope of such attacks enabled by the use of DNAME in the absence of DNSSEC. While I understand the point that cache poisoning (and even cache poisoning with DNAME) is already possible, given that this document is setting up a broadly scoped public infrastructure that could be used in such attacks, I believe it should either enumerate them or point to a document that does. Similarly, I believe the scope of section 6 needs to be broader. It currently covers the set of potential responses when DNAME is not supported by a standard resolver. Sadly, there are deployments of systems which, politely put, "augment" the results when resolution returns an NXDOMAIN. The behaviour of these systems can be highly problematic and, depending on the deployment, could be seriously so in this case. While these systems could be characterized as "stupid DNS tricks" they are common enough, and without warning them that a naive inference from the NXDOMAIN is likely to be wrong, we may see some serious confusion. Thanks for your attention, Ted Hardie T he IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'AS112 Redirection using DNAME' <draft-ietf-dnsop-as112-dname-04.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2014-10-08. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Subsequent to the IETF Last call on this document. questions arose as to wether the implications of using dname and therefore allowing zones other than those described by the draft and previously served by the as112 project to be served by as112 project nameservers was fully considered. We have requested an additional last call to address this question. The mechanism specified in 3.2 can be employed in practice by the managers of a zone without coordination with as112 server operators. This facilitates the deployment of additional zones for the purposes of authoritative negative answers. http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-04#section-3.2 Abstract Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ballot/ No IPR declarations have been submitted directly on this I-D.