From ajs@shinkuro.com Wed Aug 4 21:03:39 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFECE3A6A0E for ; Wed, 4 Aug 2010 21:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CppBPq9NSuvM for ; Wed, 4 Aug 2010 21:03:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 69D863A67BD for ; Wed, 4 Aug 2010 21:03:35 -0700 (PDT) Received: from crankycanuck.ca (unknown [12.176.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0F4EB1ECB408 for ; Thu, 5 Aug 2010 04:04:02 +0000 (UTC) Date: Thu, 5 Aug 2010 00:04:00 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100805040358.GE37817@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] DNSEXT charter and treating DNS names as "the same" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 04:03:39 -0000 [NOTE: Olafur & I send this to the directorate for comment before we send it to the WG. If we hear nothing by Friday afternoon, we'll send this to the namedroppers list, and also send it (maybe with a background note) to the APP and INT area discussion lists.] Dear colleagues, One of our primary goals for DNSEXT at IETF 78 was to get feedback from the user community (in particular, application developers) who have the "aliasing" and "sameness" problem(s) with the DNS. Unfortunately, we were unable to attract many such participants. It is clear to us that none of the proposals now before DNSEXT addresses all the problems that people have. As far as we are able to tell, there are needs with respect to domain names, with respect to whole trees in the DNS, and perhaps with respect to individual labels no matter where they might appear in a domain name. None of the proposals handles all of these, and some of these needs are not addressed at all. We appear to be faced with a choice among three basic strategies: 1. Experiment: Since we don't know what the problems are, but we have people proposing solutions, we could adopt the proposed solutions experimentally, and evaluate in (say) five years whether the proposals solved the problems people have. 2. Limp along: We could accept that no proposal will solve everything, and "limp along" by standardizing properly the proposals we have, working towards clarity and precision in the problem statement and then proceeding to work on the proposals themselves. 3. Kick it upstairs: A basic problem in all of this is that the DNS does not have a presentation layer. Domain names end up being used in presentation contexts, and that's what's broken. So, we could say that there is no problem here for the DNS, but that we are ready and willing to support building a presentation layer atop the DNS. Such a specification needs to come from elsewhere. The problem with (1) is that some of the proposals are simply impossible to do as experiments (if we change the rules for CNAME, they're effectively changed forever whether we like it or not). In addition, we think it would be a very bad idea to perform such an experiment in the root, but we expect that there would be operational pressures to do so. The problem with (2) is that we make the DNS more complicated without solving all or perhaps even most of the problems people really have. The complication will be greater than many people seem to think: for instance, the BNAME proposal as it is currently written is, as far as we can tell, simply incompatible with all the deployed validators in the world. That seems like a problem that needs addressing, and we can't see how to do so easily. The problem with (3) is that it was suggested before, and got no traction. Moreover, it's very complicated, such that the work might never complete; and in the meantime, people who have a problem have no help. We DNSEXT chairs are mostly convinced that there is no current proposal that is any simpler than just duplicating zone apex data and adding a DNAME to the "alias" zones. (This suggests an option 4, which is "document how to do this by provisioning, thereby explaining why the WG is not doing anything else.) Before we propose another charter for the WG, we'd like to hear more arguments why any work is needed, and which of the options 1-3 seem like the best bet for that work. Best regards, Andrew and Olafur -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paf@cisco.com Wed Aug 4 22:26:07 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCB23A69E6 for ; Wed, 4 Aug 2010 22:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OHWK1zH0OQB for ; Wed, 4 Aug 2010 22:26:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C20153A6AA7 for ; Wed, 4 Aug 2010 22:25:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAvoWUxAZnwN/2dsb2JhbACgNHGnZZskhToEiSU X-IronPort-AV: E=Sophos;i="4.55,319,1278288000"; d="sig'?scan'208";a="143561674" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Aug 2010 05:26:16 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp6582.cisco.com [10.61.89.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o755QFK7009752; Thu, 5 Aug 2010 05:26:15 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-70--116418999" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100805040358.GE37817@shinkuro.com> Date: Thu, 5 Aug 2010 07:26:15 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3BB283ED-30B2-4B9D-814C-8CD54B501370@cisco.com> References: <20100805040358.GE37817@shinkuro.com> To: Andrew Sullivan X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: dns-dir@ietf.org Subject: Re: [dns-dir] DNSEXT charter and treating DNS names as "the same" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 05:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-70--116418999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this is fine. I still feel the title of the draft of Suzanne = makes sense, and the problem I see is the following: Given that someone has decided that resolution of A and B (and children = of A and B) should result in the "same thing", how should the domain = holder implement that? Just by provisioning? Works if the there is the same registry for A and = B, but otherwise it is very difficult. I think personally your alternative four is probably "good enough for = now" until we have more data. The problem in the live is that too many = people still say "DNAME is dangerous -- do not use it" but I have not = really seen any real evidence for problems with DNAME, specifically if = one say DNAME is to be implemented only within one zone and similar = restrictions. And of course it is easier when we have the push for = DNSSEC. So I think your note is good. Patrik On 5 aug 2010, at 06.04, Andrew Sullivan wrote: > [NOTE: Olafur & I send this to the directorate for comment before we > send it to the WG. If we hear nothing by Friday afternoon, we'll send > this to the namedroppers list, and also send it (maybe with a > background note) to the APP and INT area discussion lists.] >=20 > Dear colleagues, >=20 > One of our primary goals for DNSEXT at IETF 78 was to get feedback > from the user community (in particular, application developers) who > have the "aliasing" and "sameness" problem(s) with the DNS. > Unfortunately, we were unable to attract many such participants.=20 >=20 > It is clear to us that none of the proposals now before DNSEXT > addresses all the problems that people have. As far as we are able to > tell, there are needs with respect to domain names, with respect to > whole trees in the DNS, and perhaps with respect to individual labels > no matter where they might appear in a domain name. None of the > proposals handles all of these, and some of these needs are not > addressed at all. >=20 > We appear to be faced with a choice among three basic strategies: >=20 > 1. Experiment: Since we don't know what the problems are, but we > have people proposing solutions, we could adopt the proposed > solutions experimentally, and evaluate in (say) five years whether > the proposals solved the problems people have. >=20 > 2. Limp along: We could accept that no proposal will solve > everything, and "limp along" by standardizing properly the > proposals we have, working towards clarity and precision in the > problem statement and then proceeding to work on the proposals > themselves. >=20 > 3. Kick it upstairs: A basic problem in all of this is that the > DNS does not have a presentation layer. Domain names end up being > used in presentation contexts, and that's what's broken. So, we > could say that there is no problem here for the DNS, but that we > are ready and willing to support building a presentation layer > atop the DNS. Such a specification needs to come from elsewhere. >=20 > The problem with (1) is that some of the proposals are simply > impossible to do as experiments (if we change the rules for CNAME, > they're effectively changed forever whether we like it or not). In > addition, we think it would be a very bad idea to perform such an > experiment in the root, but we expect that there would be operational > pressures to do so. >=20 > The problem with (2) is that we make the DNS more complicated without > solving all or perhaps even most of the problems people really have. > The complication will be greater than many people seem to think: for > instance, the BNAME proposal as it is currently written is, as far as > we can tell, simply incompatible with all the deployed validators in > the world. That seems like a problem that needs addressing, and we > can't see how to do so easily. >=20 > The problem with (3) is that it was suggested before, and got no > traction. Moreover, it's very complicated, such that the work might > never complete; and in the meantime, people who have a problem have no > help. >=20 > We DNSEXT chairs are mostly convinced that there is no current > proposal that is any simpler than just duplicating zone apex data and > adding a DNAME to the "alias" zones. (This suggests an option 4, > which is "document how to do this by provisioning, thereby explaining > why the WG is not doing anything else.) Before we propose another > charter for the WG, we'd like to hear more arguments why any work is > needed, and which of the options 1-3 seem like the best bet for that > work. >=20 > Best regards, >=20 > Andrew and Olafur >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir --Apple-Mail-70--116418999 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFMWkt3vHlR2X0luNwRAli0AJ4kCMz6UMTXPPB8/wm204w8isZamwCeKQjr yPYiNQKDfG3VG/xEGM2Rb+E= =0Mus -----END PGP SIGNATURE----- --Apple-Mail-70--116418999-- From ogud@ogud.com Thu Aug 5 11:39:33 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D673A682F for ; Thu, 5 Aug 2010 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91O0VoF-geE0 for ; Thu, 5 Aug 2010 11:39:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EBEF33A6885 for ; Thu, 5 Aug 2010 11:39:30 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o75Ie0jg001575 for ; Thu, 5 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 5 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100805_184001_040813.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-hoffman-tls-keys-from-dns-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:39:33 -0000 Count: 26 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Standards Track August 4, 2010 Expires: February 5, 2011 Using Secure DNS to Retrieve Keys Used for Authenticating TLS Servers draft-hoffman-tls-keys-from-dns-00 Abstract TLS requires the use of PKIX certificates for authenticating the server. Some people want to obtain the public key used in this authentication using other methods. This document describes how to securely retrieve a TLS server's public key from the DNS. From dromasca@avaya.com Fri Aug 6 02:13:48 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF6B3A6829; Fri, 6 Aug 2010 02:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.29 X-Spam-Level: X-Spam-Status: No, score=-101.29 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm2N5GNjwC12; Fri, 6 Aug 2010 02:13:46 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 82C603A67FE; Fri, 6 Aug 2010 02:13:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,327,1278302400"; d="scan'208";a="231508425" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2010 05:14:17 -0400 X-IronPort-AV: E=Sophos;i="4.55,327,1278302400"; d="scan'208";a="497895300" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Aug 2010 05:14:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Aug 2010 11:14:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the August 12, 2010 IESG Teleconference Thread-Index: Acs08QOTAjomgGn5QG2yxoZ375cgoQAVlSyA From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , "IETF DNS Directorate" , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 12, 2010 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 09:13:48 -0000 Please find below the preliminary agenda of the 8/12 telechat. Please let me know any comments, issues and concerns about the documents and charters brought up for approval before 8/11 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, August 06, 2010 1:53 AM .... 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ippm-spatial-composition-15 Spatial Composition of Metrics (Proposed Standard) Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd. Token: Lars Eggert o draft-ietf-manet-nhdp-14 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (Proposed Standard) Note: Ian Chakeres (ian.chakeres@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-behave-v6v4-xlate-stateful-12 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (Proposed Standard) Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. Token: David Harrington o draft-ietf-behave-address-format-09 IPv6 Addressing of IPv4/IPv6 Translators (Proposed Standard) Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. Token: David Harrington o draft-ietf-isis-ipv6-te-07 IPv6 Traffic Engineering in IS-IS (Proposed Standard) Token: Stewart Bryant o draft-ietf-behave-v6v4-xlate-20 IP/ICMP Translation Algorithm (Proposed Standard) Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. Token: David Harrington o draft-ietf-ippm-twamp-reflect-octets-07 TWAMP Reflect Octets and Symmetrical Size Features (Proposed Standard) Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd. Token: Lars Eggert o draft-ietf-softwire-ds-lite-tunnel-option-03 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite (Proposed Standard) Note: Dave Ward (dward@juniper.net) is the document shepherd. Token: Ralph Droms 2.1.2 Returning Items o draft-ietf-tls-rfc4366-bis-10 Transport Layer Security (TLS) Extensions: Extension Definitions (Proposed Standard) Note: Document shepherd is Joe Salowey=20 Token: Sean Turner 2.2 Individual Submissions 2.2.1 New Items o draft-elie-nntp-list-additions-03 Network News Transfer Protocol (NNTP) Additions to LIST Command (Proposed Standard) Token: Alexey Melnikov 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ipsecme-roadmap-08 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (Informational) Note: Paul Hoffman (paul.hoffman@vpnc.org) the document shepherd for this document. Token: Sean Turner o draft-ietf-behave-v6v4-framework-09 Framework for IPv4/IPv6 Translation (Informational) Note: Dan Wing (dwing@cisco.com) is the document shepherd. Token: David Harrington o draft-ietf-forces-applicability-09 ForCES Applicability Statement (Informational) Note: The Document Shepherd is Jamal Hadi Salim (hadi@mojatatu.com). Token: Adrian Farrel o draft-ietf-forces-implementation-report-02 Implementation Report for ForCES (Informational) Note: Joel Halpern (jmh@joelhalpern.com) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-v6ops-ipv6-cpe-router-06 Basic Requirements for IPv6 Customer Edge Routers (Informational) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica o draft-ietf-v6ops-isp-scenarios-00 Emerging Service Provider Scenarios for IPv6 Deployment (Informational) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-presuhn-rfc2482-historic-02 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic (Informational) Token: Alexey Melnikov o draft-davis-u-langtag-ext-03 BCP 47 Extension U (Informational) Note: Martin J. Duerst is the document shepherd Token: Alexey Melnikov 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-nir-ipsecme-childless-04 A Childless Initiation of the IKE SA (Experimental) Token: Sean Turner o draft-saito-mmusic-sdp-ike-07 Media Description for IKE in the Session Description Protocol (SDP) (Informational) Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Port Control Protocol (pcp) Token: Jari o Authority-to-Citizen Alert (atoca) Token: Robert 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Mobility EXTensions for IPv6 (mext) Token: Jari o Behavior Engineering for Hindrance Avoidance (behave) Token: David 4.2.2 Proposed for Approval o Transparent Interconnection of Lots of Links (trill) Token: Ralph From pk@DENIC.DE Fri Aug 6 06:24:55 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7013A6947 for ; Fri, 6 Aug 2010 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pldbLQzM5ox4 for ; Fri, 6 Aug 2010 06:24:54 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id E6F813A6A0B for ; Fri, 6 Aug 2010 06:24:52 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.69]) by office.denic.de with esmtp id 1OhMvK-0000E1-S3; Fri, 06 Aug 2010 15:25:22 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id B3C9D6B33FB; Fri, 6 Aug 2010 15:25:22 +0200 (CEST) Date: Fri, 6 Aug 2010 15:25:22 +0200 From: Peter Koch To: Andrew Sullivan Message-ID: <20100806132522.GF25573@unknown.office.denic.de> Mail-Followup-To: Andrew Sullivan , dns-dir@ietf.org References: <20100805040358.GE37817@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100805040358.GE37817@shinkuro.com> User-Agent: Mutt/1.4.2.1i Cc: dns-dir@ietf.org Subject: Re: [dns-dir] DNSEXT charter and treating DNS names as "the same" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 13:24:55 -0000 On Thu, Aug 05, 2010 at 12:04:00AM -0400, Andrew Sullivan wrote: > One of our primary goals for DNSEXT at IETF 78 was to get feedback > from the user community (in particular, application developers) who > have the "aliasing" and "sameness" problem(s) with the DNS. > Unfortunately, we were unable to attract many such participants. agree with the observation, but I'm not convinced that "application developers" are really the ones pushing the requirement of "sameness" or "equivalence". Unfortunately this is a layer9 more than a layer7 problem. > 2. Limp along: We could accept that no proposal will solve > everything, and "limp along" by standardizing properly the > proposals we have, working towards clarity and precision in the > problem statement and then proceeding to work on the proposals > themselves. Not sure I understand: first put the three proposals on standards track, then publish the problem statement and then revise the proposed standards? That's never going to happen. > 3. Kick it upstairs: A basic problem in all of this is that the > DNS does not have a presentation layer. Domain names end up being > used in presentation contexts, and that's what's broken. So, we > could say that there is no problem here for the DNS, but that we > are ready and willing to support building a presentation layer > atop the DNS. Such a specification needs to come from elsewhere. > > The problem with (1) is that some of the proposals are simply > impossible to do as experiments (if we change the rules for CNAME, > they're effectively changed forever whether we like it or not). In > addition, we think it would be a very bad idea to perform such an > experiment in the root, but we expect that there would be operational > pressures to do so. Smells MARID a bit, but may be a way out. On the detail level, Experimental vs Informational can be argued. "shadow zones" as it stands mixes data and control plane and could interfere with upcoming work on the "name server control protocol". Also it is unclear to me what 'adopting this draft' would actually mean for the direction of work. On "change the rules" it should be pointed out that these rules have protocol or operational reasons and can't just be changed at will. I'm not saying this wouldn't work in the CNAME+DNAME case, but it still needs some consideration beyond "works for me". > The problem with (2) is that we make the DNS more complicated without > solving all or perhaps even most of the problems people really have. > The complication will be greater than many people seem to think: for > instance, the BNAME proposal as it is currently written is, as far as > we can tell, simply incompatible with all the deployed validators in > the world. That seems like a problem that needs addressing, and we > can't see how to do so easily. > > The problem with (3) is that it was suggested before, and got no > traction. Moreover, it's very complicated, such that the work might > never complete; and in the meantime, people who have a problem have no > help. > > We DNSEXT chairs are mostly convinced that there is no current > proposal that is any simpler than just duplicating zone apex data and > adding a DNAME to the "alias" zones. (This suggests an option 4, > which is "document how to do this by provisioning, thereby explaining > why the WG is not doing anything else.) Before we propose another I think this should be elevated to a real "option 4". So, for a DNS audience I think this is a fine summary. For other audiences it might be good to give some background (see above) and to (once more) try to gather real problem descriptions/requirements. -Peter From ogud@ogud.com Fri Aug 6 09:47:00 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB273A6A0A for ; Fri, 6 Aug 2010 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTAzmRc1-7f7 for ; Fri, 6 Aug 2010 09:46:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E3D263A68AD for ; Fri, 6 Aug 2010 09:46:58 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o76GlSjp009488 for ; Fri, 6 Aug 2010 12:47:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C5C3C9E.3000107@ogud.com> Date: Fri, 06 Aug 2010 12:47:26 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: dns-dir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 12, 2010 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:47:00 -0000 Early warning has number of documents that are on the agenda in the early warning data base. I'm leaving for a vacation, and can not review them. Can people that have read the documents please put out a statement as to if the document is one of the following: a. OK b. Needs to be looked at c. Should not pass thanks Olafur behave-address-format 00 11 behave-v6v4-framework 00 52 01 53 02 53 03 49 04 49 05 56 06 56 07 56 08 54 09 54 behave-v6v4-xlate-stateful 00 36 01 38 02 38 03 38 04 37 05 36 06 36 07 36 08 20 09 20 10 20 11 20 12 20 behave-v6v4-xlate-stateful 00 36 01 38 02 38 03 38 04 37 05 36 06 36 07 36 08 20 09 20 10 20 11 20 12 20 v6ops-ipv6-cpe-router 00 20 wbeebee-v6ops-ipv6-cpe-router-bis 00 16 01 16 02 15 03 15 carpenter-v6ops-isp-scenarios 01 15 02 15 v6ops-isp-scenarios 00 15 On 06/08/2010 5:14 AM, Romascanu, Dan (Dan) wrote: > Please find below the preliminary agenda of the 8/12 telechat. Please > let me know any comments, issues and concerns about the documents and > charters brought up for approval before 8/11 COB. > > Thanks and Regards, > > Dan > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > IESG Secretary > Sent: Friday, August 06, 2010 1:53 AM > > .... > > 2. Protocol Actions > 2.1 WG Submissions > 2.1.1 New Items > > o draft-ietf-ippm-spatial-composition-15 > Spatial Composition of Metrics (Proposed Standard) > Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd. > Token: Lars Eggert > > o draft-ietf-manet-nhdp-14 > Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) > (Proposed Standard) > Note: Ian Chakeres (ian.chakeres@gmail.com) is the document > shepherd. > Token: Stewart Bryant > > o draft-ietf-behave-v6v4-xlate-stateful-12 > Stateful NAT64: Network Address and Protocol Translation from IPv6 > Clients to IPv4 Servers (Proposed Standard) > Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. > Token: David Harrington > > o draft-ietf-behave-address-format-09 > IPv6 Addressing of IPv4/IPv6 Translators (Proposed Standard) > Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. > Token: David Harrington > > o draft-ietf-isis-ipv6-te-07 > IPv6 Traffic Engineering in IS-IS (Proposed Standard) > Token: Stewart Bryant > > o draft-ietf-behave-v6v4-xlate-20 > IP/ICMP Translation Algorithm (Proposed Standard) > Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd. > Token: David Harrington > > o draft-ietf-ippm-twamp-reflect-octets-07 > TWAMP Reflect Octets and Symmetrical Size Features (Proposed > Standard) > Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd. > Token: Lars Eggert > > o draft-ietf-softwire-ds-lite-tunnel-option-03 > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for > Dual- Stack Lite (Proposed Standard) > Note: Dave Ward (dward@juniper.net) is the document shepherd. > Token: Ralph Droms > > 2.1.2 Returning Items > > o draft-ietf-tls-rfc4366-bis-10 > Transport Layer Security (TLS) Extensions: Extension Definitions > (Proposed Standard) > Note: Document shepherd is Joe Salowey > Token: Sean Turner > > 2.2 Individual Submissions > 2.2.1 New Items > > o draft-elie-nntp-list-additions-03 > Network News Transfer Protocol (NNTP) Additions to LIST Command > (Proposed Standard) > Token: Alexey Melnikov > > 2.2.2 Returning Items > > NONE > > 3. Document Actions > 3.1 WG Submissions > 3.1.1 New Items > > o draft-ietf-ipsecme-roadmap-08 > IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap > (Informational) > Note: Paul Hoffman (paul.hoffman@vpnc.org) the document shepherd for > this document. > Token: Sean Turner > > o draft-ietf-behave-v6v4-framework-09 > Framework for IPv4/IPv6 Translation (Informational) > Note: Dan Wing (dwing@cisco.com) is the document shepherd. > Token: David Harrington > > o draft-ietf-forces-applicability-09 > ForCES Applicability Statement (Informational) > Note: The Document Shepherd is Jamal Hadi Salim (hadi@mojatatu.com). > Token: Adrian Farrel > > o draft-ietf-forces-implementation-report-02 > Implementation Report for ForCES (Informational) > Note: Joel Halpern (jmh@joelhalpern.com) is the Document Shepherd. > Token: Adrian Farrel > > o draft-ietf-v6ops-ipv6-cpe-router-06 > Basic Requirements for IPv6 Customer Edge Routers (Informational) > Note: Fred Baker (fred@cisco.com) is the document shepherd. > Token: Ron Bonica > > o draft-ietf-v6ops-isp-scenarios-00 > Emerging Service Provider Scenarios for IPv6 Deployment > (Informational) > Note: Fred Baker (fred@cisco.com) is the document shepherd. > Token: Ron Bonica > > 3.1.2 Returning Items > > NONE > > 3.2 Individual Submissions Via AD > 3.2.1 New Items > > o draft-presuhn-rfc2482-historic-02 > Deprecating Unicode Language Tag Characters: RFC 2482 is Historic > (Informational) > Token: Alexey Melnikov > > o draft-davis-u-langtag-ext-03 > BCP 47 Extension U (Informational) > Note: Martin J. Duerst is the > document shepherd > Token: Alexey Melnikov > > 3.2.2 Returning Items > > NONE > > 3.3 Independent Submissions Via RFC Editor > 3.3.1 New Items > > NONE > > 3.3.2 Returning Items > > NONE > > 3.3.3 For Action > > o draft-nir-ipsecme-childless-04 > A Childless Initiation of the IKE SA (Experimental) > Token: Sean Turner > > o draft-saito-mmusic-sdp-ike-07 > Media Description for IKE in the Session Description Protocol (SDP) > (Informational) > Token: Russ Housley > > 4. Working Group Actions > 4.1 WG Creation > 4.1.1 Proposed for IETF Review > > NONE > > 4.1.2 Proposed for Approval > > o Port Control Protocol (pcp) > Token: Jari > > o Authority-to-Citizen Alert (atoca) > Token: Robert > > 4.2 WG Rechartering > 4.2.1 Under Evaluation for IETF Review > > o Mobility EXTensions for IPv6 (mext) > Token: Jari > > o Behavior Engineering for Hindrance Avoidance (behave) > Token: David > > 4.2.2 Proposed for Approval > > o Transparent Interconnection of Lots of Links (trill) > Token: Ralph > > > > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir > > > From ogud@ogud.com Sat Aug 7 11:39:30 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573153A683A for ; Sat, 7 Aug 2010 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnKY4QBXbkEp for ; Sat, 7 Aug 2010 11:39:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 369863A680C for ; Sat, 7 Aug 2010 11:39:28 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o77Ie05h018193 for ; Sat, 7 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 7 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100807_184000_050228.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-opsec-protect-control-plane-02.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 18:39:30 -0000 Count: 10 OPSEC D. Dugal Internet-Draft Juniper Networks Intended status: Informational C. Pignataro Expires: February 7, 2011 R. Dunn Cisco Systems August 6, 2010 Protecting The Router Control Plane draft-ietf-opsec-protect-control-plane-02 Abstract This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level. From ajs@shinkuro.com Tue Aug 10 06:07:59 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18673A6908 for ; Tue, 10 Aug 2010 06:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbZl1egjrlzq for ; Tue, 10 Aug 2010 06:07:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A15453A687E for ; Tue, 10 Aug 2010 06:07:58 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C730F1ECB41D for ; Tue, 10 Aug 2010 13:08:32 +0000 (UTC) Date: Tue, 10 Aug 2010 09:08:31 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100810130830.GB52191@shinkuro.com> References: <20100805040358.GE37817@shinkuro.com> <20100806132522.GF25573@unknown.office.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100806132522.GF25573@unknown.office.denic.de> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] DNSEXT charter and treating DNS names as "the same" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:07:59 -0000 On Fri, Aug 06, 2010 at 03:25:22PM +0200, Peter Koch wrote: > > 2. Limp along: We could accept that no proposal will solve > > everything, and "limp along" by standardizing properly the > > proposals we have, working towards clarity and precision in the > > problem statement and then proceeding to work on the proposals > > themselves. > > Not sure I understand: first put the three proposals on standards track, > then publish the problem statement and then revise the proposed standards? > That's never going to happen. No. There should be a colon after "have" instead of a comma. Sorry. I'll fix before posting. Thanks for the comments, both you and Patrik. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Wed Aug 11 11:39:28 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCA93A67F5 for ; Wed, 11 Aug 2010 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.465 X-Spam-Level: X-Spam-Status: No, score=-101.465 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DzFjrRzerNL for ; Wed, 11 Aug 2010 11:39:28 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E0F7B3A67E2 for ; Wed, 11 Aug 2010 11:39:24 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7BIe0d3051012 for ; Wed, 11 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 11 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100811_184000_021152.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-yao-dnsext-alias-algorithm-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 18:39:28 -0000 Count: 43 Network Working Group Jiankang. Yao Internet-Draft Jian. Jin Intended status: Standards Track Wei. Mao Expires: February 12, 2011 CNNIC August 11, 2010 Alias algorithm identifier assignment mechanism for DNSSEC draft-yao-dnsext-alias-algorithm-00.txt Abstract DNS Security Extensions (DNSSEC) has been developed to provide origin authentication and integrity protection for DNS data by using digital signatures. The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the security algorithm being used. More and more new RRTYPEs will appear in future. This document defines an alias algorithm identifier assignment method for DNSSEC 8-bit algorithm numbers. From ajs@shinkuro.com Thu Aug 12 07:44:20 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552923A68FC for ; Thu, 12 Aug 2010 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5ar2Eppy-ck for ; Thu, 12 Aug 2010 07:44:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7F92B3A690C for ; Thu, 12 Aug 2010 07:44:19 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BB24A1ECB41D for ; Thu, 12 Aug 2010 14:44:54 +0000 (UTC) Date: Thu, 12 Aug 2010 10:44:52 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100812144452.GC63338@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 14:44:20 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Will someone please review this? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --ZPt4rx8FFjLCG7dd Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from zinfandel.tools.ietf.org ([64.170.98.42] verified) by execdsl.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 18829558 for ajs@shinkuro.com; Thu, 12 Aug 2010 07:59:29 -0600 Received-SPF: none receiver=execdsl.com; client-ip=64.170.98.42; envelope-from=tim.polk@nist.gov Received: from mail.ietf.org ([2001:1890:1112:1::20]) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OjYNR-0005Pi-EH; Thu, 12 Aug 2010 07:03:25 -0700 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47573A6A3F; Thu, 12 Aug 2010 07:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsKluCyJUpU2; Thu, 12 Aug 2010 07:02:47 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FB03A6A27; Thu, 12 Aug 2010 07:02:47 -0700 (PDT) From: Tim Polk To: iesg@ietf.org Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-dns64@tools.ietf.org X-Test-IDTracker: no Message-ID: <20100812140247.32320.90067.idtracker@localhost> Date: Thu, 12 Aug 2010 07:02:47 -0700 X-SA-Exim-Connect-IP: 2001:1890:1112:1::20 X-SA-Exim-Rcpt-To: behave-chairs@tools.ietf.org, draft-ietf-behave-dns64@tools.ietf.org X-SA-Exim-Mail-From: tim.polk@nist.gov X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,X_IPV6_ADDRESS autolearn=ham version=3.3.1 Subject: DISCUSS: X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Discuss: I have some concerns regarding the impact on DNSSEC aware clients. Is expecting these systems to be translation-aware practical? I noticed the writeup mentioned the need for the DNS directorate review, but my review of the dns-dir archives did not turn up a review. If the DNS directorate has reviewed this document and supports publication I will clear. --ZPt4rx8FFjLCG7dd-- From dromasca@avaya.com Tue Aug 17 10:40:23 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D5D3A6AFD; Tue, 17 Aug 2010 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETQYhhtXpYkg; Tue, 17 Aug 2010 10:39:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 33AFC3A6A9E; Tue, 17 Aug 2010 10:36:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,384,1278302400"; d="scan'208";a="233278744" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Aug 2010 13:34:04 -0400 X-IronPort-AV: E=Sophos;i="4.55,384,1278302400"; d="scan'208";a="496835300" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Aug 2010 13:34:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Aug 2010 19:33:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Mobility EXTensions for IPv6 (mext) Thread-Index: Acs+MgW/sEK+BB5mR0CoamWpoX4MrQAAEqrQ From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: WG Review: Recharter of Mobility EXTensions for IPv6 (mext) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:40:23 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, August 17, 2010 8:30 PM To: ietf-announce@ietf.org Cc: marcelo@it.uc3m.es; julienl@qualcomm.com; mext@ietf.org Subject: WG Review: Recharter of Mobility EXTensions for IPv6 (mext)=20 A modified charter has been submitted for the Mobility EXTensions for IPv6 (mext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 24, 2010. Mobility EXTensions for IPv6 (mext) --------------------------------------------- Status: Active Working Group Last updated: 2010-07-28 Chairs: Marcelo Bagnulo Julien Laganier Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions.=20 In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6) o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. The MEXT WG will also explore experimental alternative security mechanisms. The security mechanism specified in the existing standard track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement mechanism that guarantees interoperability between different implementations. The MEXT WG is chartered to deliver one or more experimental alternative mechanisms. All the alternative solutions will be published as experimental RFCs. In addition, the working group will bring to completion earlier work on prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 operation with firewalls, and home agent reliability specifications. Work items related to base specification maintenance include: Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. Goals and Milestones: Dec 2010 Submit the final doc on Prefix Delegation for NEMO to the=20 IESG, for Proposed Standard Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for=20 publication as a proposed standard. Jan 2010 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG=20 for publication as Informational. Dec 2010 Submit I-D(s) related to specific updates and corrections=20 of RFC 3775 to IESG for publication as Proposed Standard. Jan 2011 Submit I-D 'Home agent reliability' to IESG for publication=20 as a Proposed Standard. Aug 2011 Submit I-Ds on alternative security mechanisms to the IESG=20 for publication as experimental From rdroms.ietf@gmail.com Wed Aug 18 04:31:27 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF773A6922 for ; Wed, 18 Aug 2010 04:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fscOVVuuuBBl for ; Wed, 18 Aug 2010 04:31:25 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A7C733A68B8 for ; Wed, 18 Aug 2010 04:31:25 -0700 (PDT) Received: by qwc9 with SMTP id 9so408200qwc.31 for ; Wed, 18 Aug 2010 04:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=aVXPtUdKFdCNjmyvbo/fjjcM1EM3vsugluFcwemvizQ=; b=fe16eJVhe0jAcddBu7ClLA9MBD87hcIR3uiVJKz00nG6H9Ymz5pDgZjJBDPba4Tt1Y vq2xuiSgGrDkjbmcJLrUkV74BOVEhJyR0u0Bszf9XU7DvreW5C/KVxL/3qLAoiRbjTvV I0LxExgKs/UEp2VKQ8yt2ER2Q+Gd1jeny+n3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=jHIQBuwjnD6strOZ2tcXPe1QXr+1prYv+JRUzmMv9bFJDP+lte0lyAhvsTyesBL+JQ AR+EZ45wcXKl22Y5aSVpMdaFH49NeebnDJVYGEIFGM/Ac48SoUnRhVPqjPFe8m68ThNT MpPJ2XHrPn3BbWeqwInhj93TII+kUq4S608SQ= Received: by 10.224.54.85 with SMTP id p21mr5249652qag.378.1282131120795; Wed, 18 Aug 2010 04:32:00 -0700 (PDT) Received: from bxb-rdroms-8718.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id l8sm148373qck.6.2010.08.18.04.31.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 04:31:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20100812144452.GC63338@shinkuro.com> Date: Wed, 18 Aug 2010 07:31:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> References: <20100812144452.GC63338@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1078) Cc: IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 11:31:27 -0000 Andrew, Directorate - I've been asked again by the IESG for a = Directorate review of this document. I need a volunteer to read and = comment as soon as possible. Thanks. - Ralph On Aug 12, 2010, at 10:44 AM 8/12/10, Andrew Sullivan wrote: > Hi, >=20 > Will someone please review this? >=20 > A > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. >=20 > From: Tim Polk > Date: August 12, 2010 10:02:47 AM EDT > To: iesg@ietf.org > Cc: behave-chairs@tools.ietf.org, = draft-ietf-behave-dns64@tools.ietf.org > Subject: DISCUSS: >=20 >=20 > Discuss: > I have some concerns regarding the impact on DNSSEC aware clients. Is = expecting these systems to be > translation-aware practical? I noticed the writeup mentioned the need = for the DNS directorate review, but my > review of the dns-dir archives did not turn up a review. If the DNS = directorate has reviewed this document and > supports publication I will clear. >=20 >=20 >=20 >=20 > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From ogud@ogud.com Wed Aug 18 11:39:38 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2E23A6A6A for ; Wed, 18 Aug 2010 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUo0g-TUqNQX for ; Wed, 18 Aug 2010 11:39:34 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D85653A6A72 for ; Wed, 18 Aug 2010 11:39:30 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7IIe1V7049635 for ; Wed, 18 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 18 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100818_184001_070925.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-sury-dnsext-cname-at-apex-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:39:38 -0000 Count: 13 DNSext Working Group O. Sury Internet-Draft CZ.NIC Updates: 1034 (if approved) August 18, 2010 Intended status: Standards Track Expires: February 19, 2011 CNAME at the zone apex draft-sury-dnsext-cname-at-apex-00 Abstract This document proposes a modification to CNAME record to coexist with SOA and NS records at the zone apex. This proposal will improve aliasing in the DNS system. The users are often forced to manually add duplicate A, AAAA and MX records by copying data from the target zone to the aliased zone. This forces zone owner to keep track of target domain name since the mismatch in the data could cause failures. This administrative burden will be eliminated by allowing CNAME to coexist with NS and SOA resource records. From paf@cisco.com Thu Aug 19 02:27:46 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A3D3A68E6 for ; Thu, 19 Aug 2010 02:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_40=-0.185, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtSMSa5SZCS5 for ; Thu, 19 Aug 2010 02:27:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A28F53A6909 for ; Thu, 19 Aug 2010 02:27:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHeWbExAZnwN/2dsb2JhbACgWXGgRpt5hTcEiXE X-IronPort-AV: E=Sophos;i="4.56,232,1280707200"; d="scan'208";a="149588417" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2010 09:28:02 +0000 Received: from [10.55.82.55] (dhcp-10-55-82-55.cisco.com [10.55.82.55]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7J9Rxjb029004; Thu, 19 Aug 2010 09:28:00 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> Date: Thu, 19 Aug 2010 11:21:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CB9D872-B251-40F6-AA2B-CCD79B8B1C33@cisco.com> References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1081) Cc: IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:27:46 -0000 On 18 aug 2010, at 13.31, Ralph Droms wrote: > Andrew, Directorate - I've been asked again by the IESG for a = Directorate review of this document. I need a volunteer to read and = comment as soon as possible. Thanks. Here are my comments on the draft: In the introduction: > These mechanisms are expected to play a critical role in the IPv4- > IPv6 transition and co-existence. Due to IPv4 address depletion, = it > is likely that in the future, many IPv6-only clients will want to > connect to IPv4-only servers. In the typical case, the approach = only > requires the deployment of IPv6/IPv4 translators that connect an > IPv6-only network to an IPv4-only network, along with the = deployment > of one or more DNS64-enabled name servers. However, some advanced > features require performing the DNS64 function directly in the end- > hosts themselves. I do not like words like "advanced" in texts like these. Why is for = example "validation of DNSSEC records in the end host resolver" to be = "advanced"? In the non-normative section, the following important information = exists: > (NOTE: By IPv6-only hosts we mean hosts running IPv6-only > applications, hosts that can only use IPv6, as well as cases where > only IPv6 connectivity is available to the client. By IPv4-only > servers we mean servers running IPv4-only applications, servers = that > can only use IPv4, as well as cases where only IPv4 connectivity is > available to the server). > 3. Background to DNS64-DNSSEC interaction As section 2 explicitly is non-normative, is section 3 normative as it = is not say that it is not? > Here are the possible cases: I think personally it would be better to, for each of the alternatives, = compare the DNS64 impact on resolver and server than list (again) a more = comprehensive DNSSEC behaviour list like this. But that is a personal = opinion. > 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query = with > the DO bit clear. In this case, DNSSEC is not a concern, = because > the querying agent does not understand DNSSEC responses. Should not it be mentioned that the DNS64, if being a DNS64 resolver, = very well can do validation of the response, and act according to local = policy? Similar to a case 5, but with local policy? > 4. A security-aware and non-validating DNS64 receives a query with > the DO bit set and the CD bit set. In this case, the resolver = is What is "resolver" in this sentence? Looks to me that this is written = only for the "DNS64 resolver" cases and not the DNS64 server case? > supposed to pass on all the data it gets to the query initiator > (see section 3.2.2 of [RFC4035]). This case will not work with > DNS64, unless the validating resolver is prepared to do DNS64 > itself. If the DNS64 server modifies the record, the client = will Here one say "DNS64 server" and claim that it "modifies" the record. I = do not understand what "modifies" implies at an authoritative server, as = for me whatever comes from an authoritative server is the authoritative = record. There is nothing that is modified. The records (the AAAA = records) can in the case of a DNS64 server very well be signed AAAA = records that are very stable and never changed. I.e. pre-populated in = the zone and not at all something that is synthesized, and signed! > get the data back and try to validate it, and the data will be > invalid as far as the client is concerned. >=20 > 5. A security-aware and validating DNS64 node receives a query = with Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, = i.e. one of the three cases? I think in reality it is one of the "DNS64 = resolver" cases one talk about here, and not "DNS64 server". > the DO bit clear and CD clear. In this case, the resolver > validates the data. If it fails, it returns RCODE 2 (Server > failure); otherwise, it returns the answer. This is the ideal > case for vDNS64. The resolver validates the data, and then > synthesizes the new record and passes that to the client. The > client, which is presumably not validating (else it should have > set DO and CD), cannot tell that DNS64 is involved. >=20 > 6. A security-aware and validating DNS64 node receives a query = with See comment above about "DNS64 node". > the DO bit set and CD clear. This works like the previous = case, > except that the resolver should also set the "Authentic Data" > (AD) bit on the response. >=20 > 7. A security-aware and validating DNS64 node receives a query = with See comment above about "DNS64 node". > the DO bit set and CD set. This is effectively the same as the > case where a security-aware and non-validating recursive = resolver > receives a similar query, and the same thing will happen: the > downstream validator will mark the data as invalid if DNS64 has > performed synthesis. The node needs to do DNS64 itself, or = else > communication will fail. > 4. Terminology I presume this is normative section. See comment above. > Authoritative server: A DNS server that can answer authoritatively = a > given DNS question. Is "question" the correct term? I ask... I try to say "Respond authoritatively to a DNS request" but I also know = that some people do think it is a good thing to say query/answer when it = explicitly is a query we talk about. > DNS64: A logical function that synthesizes DNS resource records = (e.g > AAAA records containing IPv6 addresses) from DNS resource = records > actually contained in the DNS (e.g., A records containing IPv4 > addresses). Does it have to be synthesized? Also if it is a DNS64 server? > DNS64 recursor: A recursive resolver that provides the DNS64 > functionality as part of its operation. This is the same thing = as > "DNS64 in recursive resolver mode". Above, in the non-normative section, this was called "DNS64 resolver" as = well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, should = not "DNS64 stub" also be defined? > DNS64 resolver: Any resolver (stub resolver or recursive resolver) > that provides the DNS64 function. >=20 > DNS64 server: Any server providing the DNS64 function. Authoritative server, or also resolvers? > Recursive resolver: A DNS server that accepts requests from one > resolver, and asks another server (of some description) for the > answer on behalf of the first resolver. Is this the same definition as in other documents? > Synthetic RR: A DNS resource record (RR) that is not contained in > any zone data file, but has been synthesized from other RRs. An > example is a synthetic AAAA record created from an A record. Mumble, is "zone data file" a good wording? Should one not talk about = "generated on request" instead? Maybe it is the best wording? Although = some records might be in a database, and not at all in a file. > IPv6/IPv4 translator: A device that translates IPv6 packets to = IPv4 > packets and vice-versa. It is only required that the > communication initiated from the IPv6 side be supported. > 5. DNS64 Normative Specification Here suddenly the normative part comes... > DNS64 is a logical function that synthesizes AAAA records from A > records. The DNS64 function may be implemented in a stub resolver, > in a recursive resolver, or in an authoritative name server. In an authoritative server they do not have to be synthesized. > DNS64 also responds to PTR queries involving addresses containing = any > of the IPv6 prefixes it uses for synthesis of AAAA RRs. > 5.1.2. The answer when there is an error >=20 > If the query results in a response with RCODE other than 0 (No = error > condition), then there are two possibilities. A result with = RCODE=3D3 > (Name Error) is handled according to normal DNS operation (which is > normally to return the error to the client). This stage is still > prior to any synthesis having happened, so a response to be = returned > to the client does not need any special assembly than would usually > happen in DNS operation. >=20 > Any other RCODE is treated as though the RCODE were 0 and the = answer > section were empty. Maybe a reference to 5.1.6/5.1.7 (see below) here. > 5.1.4. Special exclusion set for AAAA records This section is confusing, as other 5.1.* sections are alternatives. = I.e. "issue an AAAA query, and do the following if this happens". = Specifically as 5.1.4 is before 5.1.6 which is another alternative = parallel to for example 5.1.2. I.e. I think it would be better if the document was like this (not = critical though): 5. Behaviour 5.1. Queries for AAAA Issue a query for AAAA, and behave like the following: 5.1.1. A non-empty answer section, where the AAAA is not in the special = range 5.1.2. A non-empty answer section, where the AAAA is in the special = range 5.1.3. A non-empty answer section, with CNAME or DNAME 5.1.4. An answer with Errcode 3 5.1.5. Other errcodes I.e. like a flowchart. One of the subsections matches. That makes it = easier to know what to do and how to implement. > 5.1.6. Data for the answer when performing synthesis : > 5.1.7. Performing the synthesis 5.1.6 and 5.1.7 should really be merged, and the section should be = "errcode !=3D 3 and an empty answer section" > o The TTL field is set to the minimum of the TTL of the original A > RR and the SOA RR for the queried domain. (Note that in order = to > obtain the TTL of the SOA RR, the DNS64 does not need to perform = a > new query, but it can remember the TTL from the SOA RR in the > negative response to the AAAA query. If the SOA RR was not > delivered with the negative response to the AAAA query, then the > DNS64 SHOULD use a default value of 600 seconds. Not really...it should be the smallest of 600 and the TTL for the A, = right? > It is possible > instead to query explicitly for the SOA RR and use the result of > that query, but this will increase query load and time to > resolution for little additional benefit.) This is in keeping > with the approach used in negative caching ([RFC2308] Why not just stop after saying it should be the smallest of the TTL of = the A and the SOA, and then let the rest be up to the implementor? I am = nervous over more "fixed default values" for negative caching. If the = SOA was not returned, then the DNS64 have to query for it. > o The RDLENGTH field is set to 16 >=20 > o The RDATA field is set to the IPv6 representation of the IPv4 > address from the RDATA field of the A record. The DNS64 SHOULD > check each A RR against configured IPv4 address ranges and = select > the corresponding IPv6 prefix to use in synthesizing the AAAA = RR. Why only a SHOULD? And, is this not an implementation issue? If you look at the specification of DNS64, the DNS64 MUST synthesize an = AAAA record according to local policy. And then reference 5.2 for discussion about policy/algorithms? > See Section 5.2 for discussion of the algorithms to be used in > effecting the transformation. > 5.1.8. Querying in parallel >=20 > The DNS64 MAY perform the query for the AAAA RR and for the A RR in > parallel, in order to minimize the delay. However, this would = result > in performing unnecessary A RR queries in the case where no AAAA RR > synthesis is required. Why is this "however" listed in a normative specification? > A possible trade-off would be to perform them > sequentially but with a very short interval between them, so if we > obtain a fast reply, we avoid doing the additional query. (Note = that > this discussion is relevant only if the DNS64 function needs to > perform external queries to fetch the RR. If the needed RR > information is available locally, as in the case of an = authoritative > server, the issue is no longer relevant.) Everything from "However..." can be deleted. There is nothing in 5.1 (what to do when querying for AAAA records) = about the additional or authoritative section. > 5.2. Generation of the IPv6 representations of IPv4 addresses Should not queries for other RR Types be in 5.2, and this be part of the = "synthesizing responses" above, or some other section? > 5.3. Handling other Resource Records and the Additional Section >=20 > 5.3.1. PTR Resource Record >=20 > If a DNS64 server receives a PTR query for a record in the IP6.ARPA > domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse = the > address portion of the QNAME according to the encoding scheme > outlined in section 2.5 of [RFC3596], and examine the resulting > address to see whether its prefix matches any of the locally- > configured Pref64::/n. ...or the default well known prefix (that was not to be configured). > There are two alternatives for a DNS64 server What about DNS64 resolvers that receive PTR queries? > 2. The second option is for the DNS64 nameserver to synthesize a > CNAME mapping the IP6.ARPA namespace to the corresponding IN- > ADDR.ARPA name. Is this safe? I.e. it is clear no other RR Type than PTR exists with = this owner? See Apple Bonjour for example. A query for a PTR record might not have owner in the IP6.ARPA, so 5.3.1 = is really for PTR records in the IP6.ARPA domain. What about other PTR = queries? I guess the answer is here: > If the address prefix does not match any Pref64::/n, then the DNS64 > server MUST process the query as though it were any other query; = i.e. > a recursive nameserver MUST attempt to resolve the query as though = it > were any other (non-A/AAAA) query, and an authoritative server MUST > respond authoritatively or with a referral, as appropriate. No other RR Types need special treatment? I.e. the flow is weird here as well in the document. Because other RR = Types comes as 5.3.3. > 5.3.2. Handling the additional section >=20 > DNS64 synthesis MUST NOT be performed on any records in the > additional section of synthesized answers. The DNS64 MUST pass the > additional section unchanged. The normative part of 5.3.2 should stop here. Remove the rest or move to = non-normative section of this document. > 5.4. Assembling a synthesized response to a AAAA query Here we have some text on how to do synthesis again? Should not this be part of 5.1 that is about AAAA? > 5.5. DNSSEC processing: DNS64 in recursive resolver mode >=20 > We consider the case where a recursive resolver that is performing > DNS64 also has a local policy to validate the answers according to > the procedures outlined in [RFC4035] Section 5. We call this = general > case vDNS64. Then this is really: 5.5. DNSSEC processing: DNS64 in validating recursive resolver > The vDNS64 uses the presence of the DO and CD bits to make some > decisions about what the query originator needs, and can react > accordingly: >=20 > 1. If CD is not set and DO is not set, vDNS64 SHOULD perform > validation and do synthesis as needed. See the next item for > rules about how to do validation and synthesis. In this case, > however, vDNS64 MUST NOT set the AD bit in any response. >=20 > 2. If CD is not set and DO is set, then vDNS64 SHOULD perform > validation. Whenever vDNS64 performs validation, it MUST > validate the negative answer for AAAA queries before proceeding > to query for A records for the same name, in order to be sure > that there is not a legitimate AAAA record on the Internet. > Failing to observe this step would allow an attacker to use = DNS64 > as a mechanism to circumvent DNSSEC. If the negative response > validates, and the response to the A query validates, then the > vDNS64 MAY perform synthesis and SHOULD set the AD bit in the > answer to the client. This is acceptable, because [RFC4035], > section 3.2.3 says that the AD bit is set by the name server = side > of a security-aware recursive name server if and only if it > considers all the RRSets in the Answer and Authority sections = to > be authentic. In this case, the name server has reason to > believe the RRSets are all authentic, so it SHOULD set the AD > bit. If the data does not validate, the vDNS64 MUST respond = with > RCODE=3D2 (Server failure). > A security-aware end point might take the presence of the AD = bit > as an indication that the data is valid, and may pass the DNS > (and DNSSEC) data to an application. If the application = attempts > to validate the synthesized data, of course, the validation = will > fail. One could argue therefore that this approach is not > desirable, but security aware stub resolvers must not place any > reliance on data received from resolvers and validated on their > behalf without certain criteria established by [RFC4035], = section > 4.9.3. An application that wants to perform validation on its > own should use the CD bit. Too much discussion. And (for example) last sentence have "should" in = lower case. What does that imply? Stay with what is normative. Move discussions and non-normative stuff to = some other section. > 3. If the CD bit is set and DO is set, then vDNS64 MAY perform > validation, but MUST NOT perform synthesis. It MUST return the > data to the query initiator, just like a regular recursive > resolver, and depend on the client to do the validation and the > synthesis itself. > The disadvantage to this approach is that an end point that is > translation-oblivious but security-aware and validating will = not > be able to use the DNS64 functionality. In this case, the end > point will not have the desired benefit of NAT64. In effect, > this strategy means that any end point that wishes to do > validation in a NAT64 context must be upgraded to be = translation- > aware as well. (Re)move second paragraph. > 6. Deployment notes Normative? > 7. Deployment scenarios and examples >=20 > In this section, we walk through some sample scenarios that are > expected to be common deployment cases. It should be noted that = this > is provided for illustrative purposes and this section is not > normative. Good. > 8. Security Considerations >=20 > DNS64 operates in combination with the DNS, and is therefore = subject > to whatever security considerations are appropriate to the DNS mode > in which the DNS64 is operating (i.e. authoritative, recursive, or > stub resolver mode). >=20 > DNS64 has the potential to interfere with the functioning of = DNSSEC, > because DNS64 modifies DNS answers, and DNSSEC is designed to = detect > such modification and to treat modified answers as bogus. See the > discussion above in Section 3, Section 5.5, and Section 6.2. It should be noted what might happen if the translator between IPv4 and = IPv6 is not in sync with this box. Additionally: There is no text on how to handle the query and additional section of = the request/response. Patrik From paf@cisco.com Thu Aug 19 02:28:53 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE933A6909 for ; Thu, 19 Aug 2010 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.777 X-Spam-Level: X-Spam-Status: No, score=-9.777 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnQp-65IqUhN for ; Thu, 19 Aug 2010 02:28:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 352433A68E6 for ; Thu, 19 Aug 2010 02:28:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHeWbExAZnwM/2dsb2JhbACgWXGgRpt5hTcEiXE X-IronPort-AV: E=Sophos;i="4.56,232,1280707200"; d="scan'208";a="149588777" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2010 09:29:25 +0000 Received: from [10.55.82.55] (dhcp-10-55-82-55.cisco.com [10.55.82.55]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7J9TNJL016021; Thu, 19 Aug 2010 09:29:24 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> Date: Thu, 19 Aug 2010 11:28:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1081) Cc: IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:28:53 -0000 On 18 aug 2010, at 13.31, Ralph Droms wrote: > Andrew, Directorate - I've been asked again by the IESG for a = Directorate review of this document. I need a volunteer to read and = comment as soon as possible. Thanks. Here are my comments on the draft: In the introduction: > These mechanisms are expected to play a critical role in the IPv4- > IPv6 transition and co-existence. Due to IPv4 address depletion, it > is likely that in the future, many IPv6-only clients will want to > connect to IPv4-only servers. In the typical case, the approach = only > requires the deployment of IPv6/IPv4 translators that connect an > IPv6-only network to an IPv4-only network, along with the deployment > of one or more DNS64-enabled name servers. However, some advanced > features require performing the DNS64 function directly in the end- > hosts themselves. I do not like words like "advanced" in texts like these. Why is for = example "validation of DNSSEC records in the end host resolver" to be = "advanced"? In the non-normative section, the following important information = exists: > (NOTE: By IPv6-only hosts we mean hosts running IPv6-only > applications, hosts that can only use IPv6, as well as cases where > only IPv6 connectivity is available to the client. By IPv4-only > servers we mean servers running IPv4-only applications, servers that > can only use IPv4, as well as cases where only IPv4 connectivity is > available to the server). > 3. Background to DNS64-DNSSEC interaction As section 2 explicitly is non-normative, is section 3 normative as it = is not say that it is not? > Here are the possible cases: I think personally it would be better to, for each of the alternatives, = compare the DNS64 impact on resolver and server than list (again) a more = comprehensive DNSSEC behaviour list like this. But that is a personal = opinion. > 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with > the DO bit clear. In this case, DNSSEC is not a concern, = because > the querying agent does not understand DNSSEC responses. Should not it be mentioned that the DNS64, if being a DNS64 resolver, = very well can do validation of the response, and act according to local = policy? Similar to a case 5, but with local policy? > 4. A security-aware and non-validating DNS64 receives a query with > the DO bit set and the CD bit set. In this case, the resolver = is What is "resolver" in this sentence? Looks to me that this is written = only for the "DNS64 resolver" cases and not the DNS64 server case? > supposed to pass on all the data it gets to the query initiator > (see section 3.2.2 of [RFC4035]). This case will not work with > DNS64, unless the validating resolver is prepared to do DNS64 > itself. If the DNS64 server modifies the record, the client = will Here one say "DNS64 server" and claim that it "modifies" the record. I = do not understand what "modifies" implies at an authoritative server, as = for me whatever comes from an authoritative server is the authoritative = record. There is nothing that is modified. The records (the AAAA = records) can in the case of a DNS64 server very well be signed AAAA = records that are very stable and never changed. I.e. pre-populated in = the zone and not at all something that is synthesized, and signed! > get the data back and try to validate it, and the data will be > invalid as far as the client is concerned. >=20 > 5. A security-aware and validating DNS64 node receives a query with Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, = i.e. one of the three cases? I think in reality it is one of the "DNS64 = resolver" cases one talk about here, and not "DNS64 server". > the DO bit clear and CD clear. In this case, the resolver > validates the data. If it fails, it returns RCODE 2 (Server > failure); otherwise, it returns the answer. This is the ideal > case for vDNS64. The resolver validates the data, and then > synthesizes the new record and passes that to the client. The > client, which is presumably not validating (else it should have > set DO and CD), cannot tell that DNS64 is involved. >=20 > 6. A security-aware and validating DNS64 node receives a query with See comment above about "DNS64 node". > the DO bit set and CD clear. This works like the previous case, > except that the resolver should also set the "Authentic Data" > (AD) bit on the response. >=20 > 7. A security-aware and validating DNS64 node receives a query with See comment above about "DNS64 node". > the DO bit set and CD set. This is effectively the same as the > case where a security-aware and non-validating recursive = resolver > receives a similar query, and the same thing will happen: the > downstream validator will mark the data as invalid if DNS64 has > performed synthesis. The node needs to do DNS64 itself, or else > communication will fail. > 4. Terminology I presume this is normative section. See comment above. > Authoritative server: A DNS server that can answer authoritatively = a > given DNS question. Is "question" the correct term? I ask... I try to say "Respond authoritatively to a DNS request" but I also know = that some people do think it is a good thing to say query/answer when it = explicitly is a query we talk about. > DNS64: A logical function that synthesizes DNS resource records = (e.g > AAAA records containing IPv6 addresses) from DNS resource records > actually contained in the DNS (e.g., A records containing IPv4 > addresses). Does it have to be synthesized? Also if it is a DNS64 server? > DNS64 recursor: A recursive resolver that provides the DNS64 > functionality as part of its operation. This is the same thing = as > "DNS64 in recursive resolver mode". Above, in the non-normative section, this was called "DNS64 resolver" as = well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, should = not "DNS64 stub" also be defined? > DNS64 resolver: Any resolver (stub resolver or recursive resolver) > that provides the DNS64 function. >=20 > DNS64 server: Any server providing the DNS64 function. Authoritative server, or also resolvers? > Recursive resolver: A DNS server that accepts requests from one > resolver, and asks another server (of some description) for the > answer on behalf of the first resolver. Is this the same definition as in other documents? > Synthetic RR: A DNS resource record (RR) that is not contained in > any zone data file, but has been synthesized from other RRs. An > example is a synthetic AAAA record created from an A record. Mumble, is "zone data file" a good wording? Should one not talk about = "generated on request" instead? Maybe it is the best wording? Although = some records might be in a database, and not at all in a file. > IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 > packets and vice-versa. It is only required that the > communication initiated from the IPv6 side be supported. > 5. DNS64 Normative Specification Here suddenly the normative part comes... > DNS64 is a logical function that synthesizes AAAA records from A > records. The DNS64 function may be implemented in a stub resolver, > in a recursive resolver, or in an authoritative name server. In an authoritative server they do not have to be synthesized. > DNS64 also responds to PTR queries involving addresses containing = any > of the IPv6 prefixes it uses for synthesis of AAAA RRs. > 5.1.2. The answer when there is an error >=20 > If the query results in a response with RCODE other than 0 (No error > condition), then there are two possibilities. A result with RCODE=3D3= > (Name Error) is handled according to normal DNS operation (which is > normally to return the error to the client). This stage is still > prior to any synthesis having happened, so a response to be returned > to the client does not need any special assembly than would usually > happen in DNS operation. >=20 > Any other RCODE is treated as though the RCODE were 0 and the answer > section were empty. Maybe a reference to 5.1.6/5.1.7 (see below) here. > 5.1.4. Special exclusion set for AAAA records This section is confusing, as other 5.1.* sections are alternatives. = I.e. "issue an AAAA query, and do the following if this happens". = Specifically as 5.1.4 is before 5.1.6 which is another alternative = parallel to for example 5.1.2. I.e. I think it would be better if the document was like this (not = critical though): 5. Behaviour 5.1. Queries for AAAA Issue a query for AAAA, and behave like the following: 5.1.1. A non-empty answer section, where the AAAA is not in the special = range 5.1.2. A non-empty answer section, where the AAAA is in the special = range 5.1.3. A non-empty answer section, with CNAME or DNAME 5.1.4. An answer with Errcode 3 5.1.5. Other errcodes I.e. like a flowchart. One of the subsections matches. That makes it = easier to know what to do and how to implement. > 5.1.6. Data for the answer when performing synthesis : > 5.1.7. Performing the synthesis 5.1.6 and 5.1.7 should really be merged, and the section should be = "errcode !=3D 3 and an empty answer section" > o The TTL field is set to the minimum of the TTL of the original A > RR and the SOA RR for the queried domain. (Note that in order to > obtain the TTL of the SOA RR, the DNS64 does not need to perform = a > new query, but it can remember the TTL from the SOA RR in the > negative response to the AAAA query. If the SOA RR was not > delivered with the negative response to the AAAA query, then the > DNS64 SHOULD use a default value of 600 seconds. Not really...it should be the smallest of 600 and the TTL for the A, = right? > It is possible > instead to query explicitly for the SOA RR and use the result of > that query, but this will increase query load and time to > resolution for little additional benefit.) This is in keeping > with the approach used in negative caching ([RFC2308] Why not just stop after saying it should be the smallest of the TTL of = the A and the SOA, and then let the rest be up to the implementor? I am = nervous over more "fixed default values" for negative caching. If the = SOA was not returned, then the DNS64 have to query for it. > o The RDLENGTH field is set to 16 >=20 > o The RDATA field is set to the IPv6 representation of the IPv4 > address from the RDATA field of the A record. The DNS64 SHOULD > check each A RR against configured IPv4 address ranges and select > the corresponding IPv6 prefix to use in synthesizing the AAAA RR. Why only a SHOULD? And, is this not an implementation issue? If you look at the specification of DNS64, the DNS64 MUST synthesize an = AAAA record according to local policy. And then reference 5.2 for discussion about policy/algorithms? > See Section 5.2 for discussion of the algorithms to be used in > effecting the transformation. > 5.1.8. Querying in parallel >=20 > The DNS64 MAY perform the query for the AAAA RR and for the A RR in > parallel, in order to minimize the delay. However, this would = result > in performing unnecessary A RR queries in the case where no AAAA RR > synthesis is required. Why is this "however" listed in a normative specification? > A possible trade-off would be to perform them > sequentially but with a very short interval between them, so if we > obtain a fast reply, we avoid doing the additional query. (Note = that > this discussion is relevant only if the DNS64 function needs to > perform external queries to fetch the RR. If the needed RR > information is available locally, as in the case of an authoritative > server, the issue is no longer relevant.) Everything from "However..." can be deleted. There is nothing in 5.1 (what to do when querying for AAAA records) = about the additional or authoritative section. > 5.2. Generation of the IPv6 representations of IPv4 addresses Should not queries for other RR Types be in 5.2, and this be part of the = "synthesizing responses" above, or some other section? > 5.3. Handling other Resource Records and the Additional Section >=20 > 5.3.1. PTR Resource Record >=20 > If a DNS64 server receives a PTR query for a record in the IP6.ARPA > domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse = the > address portion of the QNAME according to the encoding scheme > outlined in section 2.5 of [RFC3596], and examine the resulting > address to see whether its prefix matches any of the locally- > configured Pref64::/n. ...or the default well known prefix (that was not to be configured). > There are two alternatives for a DNS64 server What about DNS64 resolvers that receive PTR queries? > 2. The second option is for the DNS64 nameserver to synthesize a > CNAME mapping the IP6.ARPA namespace to the corresponding IN- > ADDR.ARPA name. Is this safe? I.e. it is clear no other RR Type than PTR exists with = this owner? See Apple Bonjour for example. A query for a PTR record might not have owner in the IP6.ARPA, so 5.3.1 = is really for PTR records in the IP6.ARPA domain. What about other PTR = queries? I guess the answer is here: > If the address prefix does not match any Pref64::/n, then the DNS64 > server MUST process the query as though it were any other query; = i.e. > a recursive nameserver MUST attempt to resolve the query as though = it > were any other (non-A/AAAA) query, and an authoritative server MUST > respond authoritatively or with a referral, as appropriate. No other RR Types need special treatment? I.e. the flow is weird here as well in the document. Because other RR = Types comes as 5.3.3. > 5.3.2. Handling the additional section >=20 > DNS64 synthesis MUST NOT be performed on any records in the > additional section of synthesized answers. The DNS64 MUST pass the > additional section unchanged. The normative part of 5.3.2 should stop here. Remove the rest or move to = non-normative section of this document. > 5.4. Assembling a synthesized response to a AAAA query Here we have some text on how to do synthesis again? Should not this be part of 5.1 that is about AAAA? > 5.5. DNSSEC processing: DNS64 in recursive resolver mode >=20 > We consider the case where a recursive resolver that is performing > DNS64 also has a local policy to validate the answers according to > the procedures outlined in [RFC4035] Section 5. We call this = general > case vDNS64. Then this is really: 5.5. DNSSEC processing: DNS64 in validating recursive resolver > The vDNS64 uses the presence of the DO and CD bits to make some > decisions about what the query originator needs, and can react > accordingly: >=20 > 1. If CD is not set and DO is not set, vDNS64 SHOULD perform > validation and do synthesis as needed. See the next item for > rules about how to do validation and synthesis. In this case, > however, vDNS64 MUST NOT set the AD bit in any response. >=20 > 2. If CD is not set and DO is set, then vDNS64 SHOULD perform > validation. Whenever vDNS64 performs validation, it MUST > validate the negative answer for AAAA queries before proceeding > to query for A records for the same name, in order to be sure > that there is not a legitimate AAAA record on the Internet. > Failing to observe this step would allow an attacker to use = DNS64 > as a mechanism to circumvent DNSSEC. If the negative response > validates, and the response to the A query validates, then the > vDNS64 MAY perform synthesis and SHOULD set the AD bit in the > answer to the client. This is acceptable, because [RFC4035], > section 3.2.3 says that the AD bit is set by the name server = side > of a security-aware recursive name server if and only if it > considers all the RRSets in the Answer and Authority sections to > be authentic. In this case, the name server has reason to > believe the RRSets are all authentic, so it SHOULD set the AD > bit. If the data does not validate, the vDNS64 MUST respond = with > RCODE=3D2 (Server failure). > A security-aware end point might take the presence of the AD bit > as an indication that the data is valid, and may pass the DNS > (and DNSSEC) data to an application. If the application = attempts > to validate the synthesized data, of course, the validation will > fail. One could argue therefore that this approach is not > desirable, but security aware stub resolvers must not place any > reliance on data received from resolvers and validated on their > behalf without certain criteria established by [RFC4035], = section > 4.9.3. An application that wants to perform validation on its > own should use the CD bit. Too much discussion. And (for example) last sentence have "should" in = lower case. What does that imply? Stay with what is normative. Move discussions and non-normative stuff to = some other section. > 3. If the CD bit is set and DO is set, then vDNS64 MAY perform > validation, but MUST NOT perform synthesis. It MUST return the > data to the query initiator, just like a regular recursive > resolver, and depend on the client to do the validation and the > synthesis itself. > The disadvantage to this approach is that an end point that is > translation-oblivious but security-aware and validating will not > be able to use the DNS64 functionality. In this case, the end > point will not have the desired benefit of NAT64. In effect, > this strategy means that any end point that wishes to do > validation in a NAT64 context must be upgraded to be = translation- > aware as well. (Re)move second paragraph. > 6. Deployment notes Normative? > 7. Deployment scenarios and examples >=20 > In this section, we walk through some sample scenarios that are > expected to be common deployment cases. It should be noted that = this > is provided for illustrative purposes and this section is not > normative. Good. > 8. Security Considerations >=20 > DNS64 operates in combination with the DNS, and is therefore subject > to whatever security considerations are appropriate to the DNS mode > in which the DNS64 is operating (i.e. authoritative, recursive, or > stub resolver mode). >=20 > DNS64 has the potential to interfere with the functioning of DNSSEC, > because DNS64 modifies DNS answers, and DNSSEC is designed to detect > such modification and to treat modified answers as bogus. See the > discussion above in Section 3, Section 5.5, and Section 6.2. It should be noted what might happen if the translator between IPv4 and = IPv6 is not in sync with this box. Additionally: There is no text on how to handle the query and additional section of = the request/response. Patrik From rdroms.ietf@gmail.com Thu Aug 19 04:09:56 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4810C3A68F1 for ; Thu, 19 Aug 2010 04:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.074 X-Spam-Level: X-Spam-Status: No, score=-102.074 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdqSI-SRhZ5x for ; Thu, 19 Aug 2010 04:09:53 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 5AE3C3A6816 for ; Thu, 19 Aug 2010 04:09:53 -0700 (PDT) Received: by qyk9 with SMTP id 9so1701159qyk.10 for ; Thu, 19 Aug 2010 04:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nm5IseHWxve5weFONTsxGi4Wh9u8t8DrMCI4Xu5ehlQ=; b=FP18D3IJivwl8q998aCmP7HTGcFohkBWOyMKXK9oQcONtZT6Xwl4jtUQ3McQfqtP/H WlGuuMo1vL7Jhf9IJqYl8X9qFa2PrgNldhj/2t+qZl/MWPIMmuzxp0oNiR3bY/nwXcks mSaWbDP3G/f3z1XNUxtwibT3t/cy0Z2m/NHkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=us23TBHXGuXpjt+2RDHURhGwmO+nD+8sz6YgXhhjfRFToc/OW1ZGkaV4cqC85S0QK6 7PXAjvcyPiBC6k3jiUgLfhXUtd2EpFmXv9GpLm8k0bY3NklW31IEfLBp9EtDdwWF6kMM Xbj8p9exlbObLMQ7flUnyOL38d/fC1Tc7fH1s= Received: by 10.224.2.69 with SMTP id 5mr2357756qai.111.1282216227812; Thu, 19 Aug 2010 04:10:27 -0700 (PDT) Received: from bxb-rdroms-8718.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id l8sm1564319qck.42.2010.08.19.04.10.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 04:10:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <5CB9D872-B251-40F6-AA2B-CCD79B8B1C33@cisco.com> Date: Thu, 19 Aug 2010 07:10:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4941B41F-DCA4-4885-9030-691AA6D3B17D@gmail.com> References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> <5CB9D872-B251-40F6-AA2B-CCD79B8B1C33@cisco.com> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1078) Cc: IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:09:56 -0000 Thanks, Patrik. - Ralph On Aug 19, 2010, at 5:21 AM 8/19/10, Patrik F=E4ltstr=F6m wrote: > On 18 aug 2010, at 13.31, Ralph Droms wrote: >=20 >> Andrew, Directorate - I've been asked again by the IESG for a = Directorate review of this document. I need a volunteer to read and = comment as soon as possible. Thanks. >=20 > Here are my comments on the draft: >=20 > In the introduction: >=20 >> These mechanisms are expected to play a critical role in the IPv4- >> IPv6 transition and co-existence. Due to IPv4 address depletion, = it >> is likely that in the future, many IPv6-only clients will want to >> connect to IPv4-only servers. In the typical case, the approach = only >> requires the deployment of IPv6/IPv4 translators that connect an >> IPv6-only network to an IPv4-only network, along with the = deployment >> of one or more DNS64-enabled name servers. However, some advanced >> features require performing the DNS64 function directly in the end- >> hosts themselves. >=20 > I do not like words like "advanced" in texts like these. Why is for = example "validation of DNSSEC records in the end host resolver" to be = "advanced"? >=20 > In the non-normative section, the following important information = exists: >=20 >> (NOTE: By IPv6-only hosts we mean hosts running IPv6-only >> applications, hosts that can only use IPv6, as well as cases where >> only IPv6 connectivity is available to the client. By IPv4-only >> servers we mean servers running IPv4-only applications, servers = that >> can only use IPv4, as well as cases where only IPv4 connectivity is >> available to the server). >=20 >=20 >> 3. Background to DNS64-DNSSEC interaction >=20 > As section 2 explicitly is non-normative, is section 3 normative as it = is not say that it is not? >=20 >> Here are the possible cases: >=20 > I think personally it would be better to, for each of the = alternatives, compare the DNS64 impact on resolver and server than list = (again) a more comprehensive DNSSEC behaviour list like this. But that = is a personal opinion. >=20 >> 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query = with >> the DO bit clear. In this case, DNSSEC is not a concern, = because >> the querying agent does not understand DNSSEC responses. >=20 > Should not it be mentioned that the DNS64, if being a DNS64 resolver, = very well can do validation of the response, and act according to local = policy? Similar to a case 5, but with local policy? >=20 >> 4. A security-aware and non-validating DNS64 receives a query with >> the DO bit set and the CD bit set. In this case, the resolver = is >=20 > What is "resolver" in this sentence? Looks to me that this is written = only for the "DNS64 resolver" cases and not the DNS64 server case? >=20 >> supposed to pass on all the data it gets to the query initiator >> (see section 3.2.2 of [RFC4035]). This case will not work with >> DNS64, unless the validating resolver is prepared to do DNS64 >> itself. If the DNS64 server modifies the record, the client = will >=20 > Here one say "DNS64 server" and claim that it "modifies" the record. I = do not understand what "modifies" implies at an authoritative server, as = for me whatever comes from an authoritative server is the authoritative = record. There is nothing that is modified. The records (the AAAA = records) can in the case of a DNS64 server very well be signed AAAA = records that are very stable and never changed. I.e. pre-populated in = the zone and not at all something that is synthesized, and signed! >=20 >> get the data back and try to validate it, and the data will be >> invalid as far as the client is concerned. >>=20 >> 5. A security-aware and validating DNS64 node receives a query = with >=20 > Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, = i.e. one of the three cases? I think in reality it is one of the "DNS64 = resolver" cases one talk about here, and not "DNS64 server". >=20 >> the DO bit clear and CD clear. In this case, the resolver >> validates the data. If it fails, it returns RCODE 2 (Server >> failure); otherwise, it returns the answer. This is the ideal >> case for vDNS64. The resolver validates the data, and then >> synthesizes the new record and passes that to the client. The >> client, which is presumably not validating (else it should have >> set DO and CD), cannot tell that DNS64 is involved. >>=20 >> 6. A security-aware and validating DNS64 node receives a query = with >=20 > See comment above about "DNS64 node". >=20 >> the DO bit set and CD clear. This works like the previous = case, >> except that the resolver should also set the "Authentic Data" >> (AD) bit on the response. >>=20 >> 7. A security-aware and validating DNS64 node receives a query = with >=20 > See comment above about "DNS64 node". >=20 >> the DO bit set and CD set. This is effectively the same as the >> case where a security-aware and non-validating recursive = resolver >> receives a similar query, and the same thing will happen: the >> downstream validator will mark the data as invalid if DNS64 has >> performed synthesis. The node needs to do DNS64 itself, or = else >> communication will fail. >=20 >> 4. Terminology >=20 > I presume this is normative section. See comment above. >=20 >> Authoritative server: A DNS server that can answer authoritatively = a >> given DNS question. >=20 > Is "question" the correct term? I ask... >=20 > I try to say "Respond authoritatively to a DNS request" but I also = know that some people do think it is a good thing to say query/answer = when it explicitly is a query we talk about. >=20 >> DNS64: A logical function that synthesizes DNS resource records = (e.g >> AAAA records containing IPv6 addresses) from DNS resource = records >> actually contained in the DNS (e.g., A records containing IPv4 >> addresses). >=20 > Does it have to be synthesized? Also if it is a DNS64 server? >=20 >> DNS64 recursor: A recursive resolver that provides the DNS64 >> functionality as part of its operation. This is the same thing = as >> "DNS64 in recursive resolver mode". >=20 > Above, in the non-normative section, this was called "DNS64 resolver" = as well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, = should not "DNS64 stub" also be defined? >=20 >> DNS64 resolver: Any resolver (stub resolver or recursive resolver) >> that provides the DNS64 function. >>=20 >> DNS64 server: Any server providing the DNS64 function. >=20 > Authoritative server, or also resolvers? >=20 >> Recursive resolver: A DNS server that accepts requests from one >> resolver, and asks another server (of some description) for the >> answer on behalf of the first resolver. >=20 > Is this the same definition as in other documents? >=20 >> Synthetic RR: A DNS resource record (RR) that is not contained in >> any zone data file, but has been synthesized from other RRs. An >> example is a synthetic AAAA record created from an A record. >=20 > Mumble, is "zone data file" a good wording? Should one not talk about = "generated on request" instead? Maybe it is the best wording? Although = some records might be in a database, and not at all in a file. >=20 >> IPv6/IPv4 translator: A device that translates IPv6 packets to = IPv4 >> packets and vice-versa. It is only required that the >> communication initiated from the IPv6 side be supported. >=20 >> 5. DNS64 Normative Specification >=20 > Here suddenly the normative part comes... >=20 >> DNS64 is a logical function that synthesizes AAAA records from A >> records. The DNS64 function may be implemented in a stub resolver, >> in a recursive resolver, or in an authoritative name server. >=20 > In an authoritative server they do not have to be synthesized. >=20 >> DNS64 also responds to PTR queries involving addresses containing = any >> of the IPv6 prefixes it uses for synthesis of AAAA RRs. >=20 >> 5.1.2. The answer when there is an error >>=20 >> If the query results in a response with RCODE other than 0 (No = error >> condition), then there are two possibilities. A result with = RCODE=3D3 >> (Name Error) is handled according to normal DNS operation (which is >> normally to return the error to the client). This stage is still >> prior to any synthesis having happened, so a response to be = returned >> to the client does not need any special assembly than would usually >> happen in DNS operation. >>=20 >> Any other RCODE is treated as though the RCODE were 0 and the = answer >> section were empty. >=20 > Maybe a reference to 5.1.6/5.1.7 (see below) here. >=20 >> 5.1.4. Special exclusion set for AAAA records >=20 > This section is confusing, as other 5.1.* sections are alternatives. = I.e. "issue an AAAA query, and do the following if this happens". = Specifically as 5.1.4 is before 5.1.6 which is another alternative = parallel to for example 5.1.2. >=20 > I.e. I think it would be better if the document was like this (not = critical though): >=20 > 5. Behaviour >=20 > 5.1. Queries for AAAA >=20 > Issue a query for AAAA, and behave like the following: >=20 > 5.1.1. A non-empty answer section, where the AAAA is not in the = special range >=20 > 5.1.2. A non-empty answer section, where the AAAA is in the special = range >=20 > 5.1.3. A non-empty answer section, with CNAME or DNAME >=20 > 5.1.4. An answer with Errcode 3 >=20 > 5.1.5. Other errcodes >=20 > I.e. like a flowchart. One of the subsections matches. That makes it = easier to know what to do and how to implement. >=20 >> 5.1.6. Data for the answer when performing synthesis > : >> 5.1.7. Performing the synthesis >=20 > 5.1.6 and 5.1.7 should really be merged, and the section should be = "errcode !=3D 3 and an empty answer section" >=20 >> o The TTL field is set to the minimum of the TTL of the original A >> RR and the SOA RR for the queried domain. (Note that in order = to >> obtain the TTL of the SOA RR, the DNS64 does not need to perform = a >> new query, but it can remember the TTL from the SOA RR in the >> negative response to the AAAA query. If the SOA RR was not >> delivered with the negative response to the AAAA query, then the >> DNS64 SHOULD use a default value of 600 seconds. >=20 > Not really...it should be the smallest of 600 and the TTL for the A, = right? >=20 >> It is possible >> instead to query explicitly for the SOA RR and use the result of >> that query, but this will increase query load and time to >> resolution for little additional benefit.) This is in keeping >> with the approach used in negative caching ([RFC2308] >=20 > Why not just stop after saying it should be the smallest of the TTL of = the A and the SOA, and then let the rest be up to the implementor? I am = nervous over more "fixed default values" for negative caching. If the = SOA was not returned, then the DNS64 have to query for it. >=20 >> o The RDLENGTH field is set to 16 >>=20 >> o The RDATA field is set to the IPv6 representation of the IPv4 >> address from the RDATA field of the A record. The DNS64 SHOULD >> check each A RR against configured IPv4 address ranges and = select >> the corresponding IPv6 prefix to use in synthesizing the AAAA = RR. >=20 > Why only a SHOULD? And, is this not an implementation issue? >=20 > If you look at the specification of DNS64, the DNS64 MUST synthesize = an AAAA record according to local policy. >=20 > And then reference 5.2 for discussion about policy/algorithms? >=20 >> See Section 5.2 for discussion of the algorithms to be used in >> effecting the transformation. >=20 >> 5.1.8. Querying in parallel >>=20 >> The DNS64 MAY perform the query for the AAAA RR and for the A RR in >> parallel, in order to minimize the delay. However, this would = result >> in performing unnecessary A RR queries in the case where no AAAA RR >> synthesis is required. >=20 > Why is this "however" listed in a normative specification? >=20 >> A possible trade-off would be to perform them >> sequentially but with a very short interval between them, so if we >> obtain a fast reply, we avoid doing the additional query. (Note = that >> this discussion is relevant only if the DNS64 function needs to >> perform external queries to fetch the RR. If the needed RR >> information is available locally, as in the case of an = authoritative >> server, the issue is no longer relevant.) >=20 > Everything from "However..." can be deleted. >=20 > There is nothing in 5.1 (what to do when querying for AAAA records) = about the additional or authoritative section. >=20 >> 5.2. Generation of the IPv6 representations of IPv4 addresses >=20 > Should not queries for other RR Types be in 5.2, and this be part of = the "synthesizing responses" above, or some other section? >=20 >> 5.3. Handling other Resource Records and the Additional Section >>=20 >> 5.3.1. PTR Resource Record >>=20 >> If a DNS64 server receives a PTR query for a record in the IP6.ARPA >> domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse = the >> address portion of the QNAME according to the encoding scheme >> outlined in section 2.5 of [RFC3596], and examine the resulting >> address to see whether its prefix matches any of the locally- >> configured Pref64::/n. >=20 > ...or the default well known prefix (that was not to be configured). >=20 >> There are two alternatives for a DNS64 server >=20 > What about DNS64 resolvers that receive PTR queries? >=20 >> 2. The second option is for the DNS64 nameserver to synthesize a >> CNAME mapping the IP6.ARPA namespace to the corresponding IN- >> ADDR.ARPA name. >=20 > Is this safe? I.e. it is clear no other RR Type than PTR exists with = this owner? >=20 > See Apple Bonjour for example. >=20 > A query for a PTR record might not have owner in the IP6.ARPA, so = 5.3.1 is really for PTR records in the IP6.ARPA domain. What about other = PTR queries? >=20 > I guess the answer is here: >=20 >> If the address prefix does not match any Pref64::/n, then the DNS64 >> server MUST process the query as though it were any other query; = i.e. >> a recursive nameserver MUST attempt to resolve the query as though = it >> were any other (non-A/AAAA) query, and an authoritative server MUST >> respond authoritatively or with a referral, as appropriate. >=20 > No other RR Types need special treatment? >=20 > I.e. the flow is weird here as well in the document. Because other RR = Types comes as 5.3.3. >=20 >> 5.3.2. Handling the additional section >>=20 >> DNS64 synthesis MUST NOT be performed on any records in the >> additional section of synthesized answers. The DNS64 MUST pass the >> additional section unchanged. >=20 > The normative part of 5.3.2 should stop here. Remove the rest or move = to non-normative section of this document. >=20 >> 5.4. Assembling a synthesized response to a AAAA query >=20 > Here we have some text on how to do synthesis again? >=20 > Should not this be part of 5.1 that is about AAAA? >=20 >> 5.5. DNSSEC processing: DNS64 in recursive resolver mode >>=20 >> We consider the case where a recursive resolver that is performing >> DNS64 also has a local policy to validate the answers according to >> the procedures outlined in [RFC4035] Section 5. We call this = general >> case vDNS64. >=20 > Then this is really: >=20 > 5.5. DNSSEC processing: DNS64 in validating recursive resolver >=20 >> The vDNS64 uses the presence of the DO and CD bits to make some >> decisions about what the query originator needs, and can react >> accordingly: >>=20 >> 1. If CD is not set and DO is not set, vDNS64 SHOULD perform >> validation and do synthesis as needed. See the next item for >> rules about how to do validation and synthesis. In this case, >> however, vDNS64 MUST NOT set the AD bit in any response. >>=20 >> 2. If CD is not set and DO is set, then vDNS64 SHOULD perform >> validation. Whenever vDNS64 performs validation, it MUST >> validate the negative answer for AAAA queries before proceeding >> to query for A records for the same name, in order to be sure >> that there is not a legitimate AAAA record on the Internet. >> Failing to observe this step would allow an attacker to use = DNS64 >> as a mechanism to circumvent DNSSEC. If the negative response >> validates, and the response to the A query validates, then the >> vDNS64 MAY perform synthesis and SHOULD set the AD bit in the >> answer to the client. This is acceptable, because [RFC4035], >> section 3.2.3 says that the AD bit is set by the name server = side >> of a security-aware recursive name server if and only if it >> considers all the RRSets in the Answer and Authority sections = to >> be authentic. In this case, the name server has reason to >> believe the RRSets are all authentic, so it SHOULD set the AD >> bit. If the data does not validate, the vDNS64 MUST respond = with >> RCODE=3D2 (Server failure). >> A security-aware end point might take the presence of the AD = bit >> as an indication that the data is valid, and may pass the DNS >> (and DNSSEC) data to an application. If the application = attempts >> to validate the synthesized data, of course, the validation = will >> fail. One could argue therefore that this approach is not >> desirable, but security aware stub resolvers must not place any >> reliance on data received from resolvers and validated on their >> behalf without certain criteria established by [RFC4035], = section >> 4.9.3. An application that wants to perform validation on its >> own should use the CD bit. >=20 > Too much discussion. And (for example) last sentence have "should" in = lower case. What does that imply? >=20 > Stay with what is normative. Move discussions and non-normative stuff = to some other section. >=20 >> 3. If the CD bit is set and DO is set, then vDNS64 MAY perform >> validation, but MUST NOT perform synthesis. It MUST return the >> data to the query initiator, just like a regular recursive >> resolver, and depend on the client to do the validation and the >> synthesis itself. >> The disadvantage to this approach is that an end point that is >> translation-oblivious but security-aware and validating will = not >> be able to use the DNS64 functionality. In this case, the end >> point will not have the desired benefit of NAT64. In effect, >> this strategy means that any end point that wishes to do >> validation in a NAT64 context must be upgraded to be = translation- >> aware as well. >=20 > (Re)move second paragraph. >=20 >> 6. Deployment notes >=20 > Normative? >=20 >> 7. Deployment scenarios and examples >>=20 >=20 >> In this section, we walk through some sample scenarios that are >> expected to be common deployment cases. It should be noted that = this >> is provided for illustrative purposes and this section is not >> normative. >=20 > Good. >=20 >> 8. Security Considerations >>=20 >> DNS64 operates in combination with the DNS, and is therefore = subject >> to whatever security considerations are appropriate to the DNS mode >> in which the DNS64 is operating (i.e. authoritative, recursive, or >> stub resolver mode). >>=20 >> DNS64 has the potential to interfere with the functioning of = DNSSEC, >> because DNS64 modifies DNS answers, and DNSSEC is designed to = detect >> such modification and to treat modified answers as bogus. See the >> discussion above in Section 3, Section 5.5, and Section 6.2. >=20 > It should be noted what might happen if the translator between IPv4 = and IPv6 is not in sync with this box. >=20 > Additionally: >=20 > There is no text on how to handle the query and additional section of = the request/response. >=20 > Patrik >=20 From dromasca@avaya.com Fri Aug 20 03:45:11 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179633A68EC; Fri, 20 Aug 2010 03:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFX+WaepfsjO; Fri, 20 Aug 2010 03:45:10 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 6B16E3A6822; Fri, 20 Aug 2010 03:45:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,238,1280721600"; d="scan'208";a="30784614" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 20 Aug 2010 06:43:42 -0400 X-IronPort-AV: E=Sophos;i="4.56,238,1280721600"; d="scan'208";a="505544076" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Aug 2010 06:43:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 12:43:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Package and Agenda for August 26, 2010 IESG Teleconference Thread-Index: Acs/7dsQJPP2/kfXSAqCB7rBM+vR5QAZiQmw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Package and Agenda for August 26, 2010 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:45:11 -0000 Please find below the preliminary agenda of the IESG telechat scheduled for 8/26. Please send me your comments, questions and concerns before 8/25 COB.=20 Thanks and Regards, Dan =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-msec-ipsec-group-counter-modes-05 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic (Proposed Standard) Note: Vincent Roca (vincent.roca@inria.fr) is the document shepherd. Token: Tim Polk o draft-ietf-tsvwg-ecn-tunnel-09 Tunnelling of Explicit Congestion Notification (Proposed Standard) Token: David Harrington o draft-ietf-tsvwg-dtls-for-sctp-05 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (Proposed Standard) Note: Gorry Fairhurst (gorry@erg.abdn.ac.uk ) is the document shepherd. Token: David Harrington o draft-ietf-isms-radius-vacm-09 Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings (Proposed Standard) Note: Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de) is the document shepherd. Token: Sean Turner 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-thaler-v6ops-teredo-extensions-07 Teredo Extensions (Proposed Standard) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Jari Arkko 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-mipshop-transient-bce-pmipv6-06 Transient Binding for Proxy Mobile IPv6 (Experimental) Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd Token: Jari Arkko o draft-ietf-avt-srtp-not-mandatory-07 Why RTP Does Not Mandate a Single Security Mechanism (Informational) Note: Tom Taylor (tom111.taylor@bell.net) is PROTO Shepherd. Token: Robert Sparks o draft-ietf-pkix-ta-mgmt-reqs-05 Trust Anchor Management Requirements (Informational) Note: Steve Kent is the document shepherd Token: Tim Polk o draft-ietf-mif-problem-statement-07 Multiple Interfaces Problem Statement (Informational) Note: The document shepherd is Hui Deng (denghui02@hotmail.com). Token: Jari Arkko o draft-ietf-netmod-yang-usage-10 Guidelines for Authors and Reviewers of YANG Data Model Documents (Informational) Note: David Partain (david.partain@ericsson.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-pkix-asn1-translation-02 ASN.1 Translation (Informational) Note: Steve Kent (kent@bbn.com) is the Document Shepherd. Token: Tim Polk o draft-ietf-tcpm-tcp-lcd-02 Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) (Experimental) Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Lars Eggert 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-sheffer-emu-eap-eke-07 An EAP Authentication Method Based on the EKE Protocol (Informational) Token: Russ Housley Was deferred by Alexey Melnikov on 2010-08-11 o draft-juskevicius-datatracker-wgdocstate-reqts-05 Requirements to Extend the Datatracker for WG Chairs and Authors (Informational) Token: Russ Housley Was deferred by Adrian Farrel on 2010-08-11 o draft-ietf-proto-wgdocument-states-08 Definition of IETF Working Group Document States (Informational) Token: Russ Housley Was deferred by Adrian Farrel on 2010-08-11 o draft-cakulev-mikey-ibake-02 MIKEY-IBAKE: Identity-Based Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) (Informational) Note: Requested cryptographic review by June 11 Token: Tim Polk o draft-turner-suiteb-cmc-03 Suite B Profile of Certificate Management over CMS (Informational) Note: Sean Turner (turners@ieca.com) is the document shepherd. Token: Tim Polk o draft-livingood-woundy-congestion-mgmt-07 Comcast's Protocol-Agnostic Congestion Management System (Informational) Note: AD sponsored by Lars Eggert (lars.eggert@nokia.com) Token: Lars Eggert 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Network Configuration (netconf) Token: Dan Romascanu 4.2.2 Proposed for Approval o Mobility EXTensions for IPv6 (mext) Token: Jari Arkko o Behavior Engineering for Hindrance Avoidance (behave) Token: David Harrington From rdroms.ietf@gmail.com Fri Aug 20 04:05:38 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E06E3A6A80 for ; Fri, 20 Aug 2010 04:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfyVox+2-tiy for ; Fri, 20 Aug 2010 04:05:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E81133A6A77 for ; Fri, 20 Aug 2010 04:05:33 -0700 (PDT) Received: by qwc9 with SMTP id 9so3056095qwc.31 for ; Fri, 20 Aug 2010 04:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=qOvCN4seuDHzWQJIy4MDWmf15Osqmg+avEfUMO/tG30=; b=sKtk7G90xdgBm5bBNk0faq5zxKVaPSexLAuSD1S+2xxdzCrB/2DEMNGODYU2BQYLQN ivRugK8BlXK2Y4Hs/9jUrGjEJSQTiWo4lHT2Lu9A3JZE7eGd/oeEzkq6V+TQzC1agn22 ejQhUXiBmXYbXzEDqYcSqwRszb2jrNfE3Tftk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=K5r8/hNdKSCvi8fw/zh8X9QKKnaFNOGjAbRNrwdXHTMvGXqVfcUAQRw2zBWGZMwezD iZwzJtVwPmLOELUZOs9ge7ugeiVRpwGt5fBej9HpoZNQbLyOk5vE9/DN+PfC/5kPpboy fL4yXN4sDbIQma4VeYRkYUbmG6Ozg2bCcIUp4= Received: by 10.229.192.13 with SMTP id do13mr967199qcb.30.1282302367868; Fri, 20 Aug 2010 04:06:07 -0700 (PDT) Received: from bxb-rdroms-8718.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id t18sm3035444qco.20.2010.08.20.04.06.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 04:06:07 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 07:06:04 -0400 Message-Id: <3E7F88FF-7C90-47BE-9B5A-16F3021DFF95@gmail.com> To: IETF DNS Directorate Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [dns-dir] directorate review of draft-ietf-mif-problem-statement X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:05:38 -0000 I would appreciate a quick review of draft-ietf-mif-problem-statement. = The section relevant to DNS is pretty short. I'd like to confirm that = the issues in section 4.1 are correct and clearly framed. Thanks... - Ralph From ajs@shinkuro.com Fri Aug 20 10:33:02 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF533A6AD2 for ; Fri, 20 Aug 2010 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.244 X-Spam-Level: X-Spam-Status: No, score=-101.244 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCEeoKQJa7su for ; Fri, 20 Aug 2010 10:33:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CFC633A6AF7 for ; Fri, 20 Aug 2010 10:32:59 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6C9D11ECB408; Fri, 20 Aug 2010 17:33:32 +0000 (UTC) Date: Fri, 20 Aug 2010 13:33:30 -0400 From: Andrew Sullivan To: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= , draft-ietf-behave-dns64@tools.ietf.org Message-ID: <20100820173329.GF96071@shinkuro.com> References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:33:03 -0000 Hi Patrik, Thanks for your detailed review. The document is now under IESG control, so I can make some suggestions but I can't actually make any of these changes yet. See below inline. On Thu, Aug 19, 2010 at 11:28:22AM +0200, Patrik Fältström wrote: > > of one or more DNS64-enabled name servers. However, some advanced > > features require performing the DNS64 function directly in the end- > > hosts themselves. > > I do not like words like "advanced" in texts like these. Why is for example "validation of DNSSEC records in the end host resolver" to be "advanced"? > So if we just remove it, that'd be ok? > In the non-normative section, the following important information exists: > > > (NOTE: By IPv6-only hosts we mean hosts running IPv6-only > > applications, hosts that can only use IPv6, as well as cases where > > only IPv6 connectivity is available to the client. By IPv4-only > > servers we mean servers running IPv4-only applications, servers that > > can only use IPv4, as well as cases where only IPv4 connectivity is > > available to the server). We could restate this in the definitions section. Ok? > > 3. Background to DNS64-DNSSEC interaction > > As section 2 explicitly is non-normative, is section 3 normative as it is not say that it is not? You raise this several times. I think you're right. I suggest that we alter the Introduction and state there explicitly which sections are normative and which not. Ok? > > I think personally it would be better to, for each of the alternatives, compare the DNS64 impact on resolver and server than list (again) a more comprehensive DNSSEC behaviour list like this. But that is a personal opinion. > Well, this was intended to be explanatory material for someone who was implementing this but not familiar with DNSSEC. Otherwise I was nervous that the reasoning behind not synthesizing when CD=1 wouldn't be clear. > > 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with > > the DO bit clear. In this case, DNSSEC is not a concern, because > > the querying agent does not understand DNSSEC responses. > > Should not it be mentioned that the DNS64, if being a DNS64 resolver, very well can do validation of the response, and act according to local policy? Similar to a case 5, but with local policy? > We can if you like, sure. > > 4. A security-aware and non-validating DNS64 receives a query with > > the DO bit set and the CD bit set. In this case, the resolver is > > What is "resolver" in this sentence? Looks to me that this is written only for the "DNS64 resolver" cases and not the DNS64 server case? > Ugh. It does look like we have terminological issues here. I thought I'd weeded this out in a previous pass, but I think I did it only in the normative sections, perhaps. Yuck. It is indeed supposed to include the DNS64 server case. For reasons that are not clear to me, some have insisted that a DNS authoritative server that is doing DNS64 could do so automatically, without anyone actually provisioning the AAAA records with the Pref::/64. I don't personally get this use case at all, but people have insisted on it so it's possible. > Here one say "DNS64 server" and claim that it "modifies" the record. I do not understand what "modifies" implies at an authoritative server, as for me whatever comes from an authoritative server is the authoritative record. There is nothing that is modified. The records (the AAAA records) can in the case of a DNS64 server very well be signed AAAA records that are very stable and never changed. I.e. pre-populated in the zone and not at all something that is synthesized, and signed! > Remember that strictly speaking the DNS64 is a logical function. So the name server function in the DNS64 (which is technically speaking never exposed to anyone) only provides the A record, and the DNS64 function "modifies" it. I concede that it is a little uncomfortable to talk like this, but it preserves the logical distinction between an actual DNS64 server, and a plain DNS server that happens to have in it AAAA records using the Pref::/64. Does that make sense? > > 5. A security-aware and validating DNS64 node receives a query with > > Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, i.e. one of the three cases? I think in reality it is one of the "DNS64 resolver" cases one talk about here, and not "DNS64 server". > Yeah, it's a resolver. (A DNS64 authority server never validates.) We'll have to go through and fix up the terminology to be consistent with the terminology section. > > Authoritative server: A DNS server that can answer authoritatively a > > given DNS question. > > Is "question" the correct term? I ask... > > I try to say "Respond authoritatively to a DNS request" but I also know that some people do think it is a good thing to say query/answer when it explicitly is a query we talk about. > If only the DNS geeks had a consistent set of terms, eh? Oh, wait. I'm also ok with request. > > DNS64: A logical function that synthesizes DNS resource records (e.g > > AAAA records containing IPv6 addresses) from DNS resource records > > actually contained in the DNS (e.g., A records containing IPv4 > > addresses). > > Does it have to be synthesized? Also if it is a DNS64 server? Yes. > > DNS64 recursor: A recursive resolver that provides the DNS64 > > functionality as part of its operation. This is the same thing as > > "DNS64 in recursive resolver mode". > > Above, in the non-normative section, this was called "DNS64 resolver" as well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, should not "DNS64 stub" also be defined? I don't think we have anywhere in the document where we really needed a DNS64 stub definition, so I removed it. But I'm happy to add it back if you think it helps. Dave Thaler in particular was keen that we not define additional terms we don't strictly need. > > DNS64 resolver: Any resolver (stub resolver or recursive resolver) > > that provides the DNS64 function. > > > > DNS64 server: Any server providing the DNS64 function. > > Authoritative server, or also resolvers? Any server. So it could be a recursive resolver, yes. This means that such a beast would be both a DNS64 server and a DNS64 resolver. That's consistent with the dual name of recursive servers/recursive resolvers in plain DNS, though, no? > > Recursive resolver: A DNS server that accepts requests from one > > resolver, and asks another server (of some description) for the > > answer on behalf of the first resolver. > > Is this the same definition as in other documents? Ha! If only 1034 actually defined this. RFC 4033 has this, which is as close to a definition as we have: Security-Aware Recursive Name Server: An entity that acts in both the security-aware name server and security-aware resolver roles. A more cumbersome but equivalent phrase would be "a security-aware name server that offers recursive service". We could follow the same convention, and define recursive resolver as a system that acts in both name server and resolver modes, and then we'd need to define name server and resolver. Name server is kind of defined in 1034 Sec 2.4., as is resolver. The text in 1034 is sufficiently poor that many people seem to forget that recursive name servers can end up cached (sometimes without people knowing it), and I was trying to draw that information out. But maybe this is a poor place to do so. > > Synthetic RR: A DNS resource record (RR) that is not contained in > > any zone data file, but has been synthesized from other RRs. An > > example is a synthetic AAAA record created from an A record. > > Mumble, is "zone data file" a good wording? Should one not talk about "generated on request" instead? Maybe it is the best wording? Although some records might be in a database, and not at all in a file. > Yeah, I originally had just "any zone data", and someone insisted that wasn't good enough because the synthetic RR could be in a cache somewhere. (For the same reason, "generated on request" won't exactly work either.) What about this: Synthetic RR: A DNS resource record (RR) that is not contained in the authoritative servers' zone data, but which is instead sythesized from other RRs in the same zone. An example is a synthetic AAAA record created from an A record. ? > > DNS64 is a logical function that synthesizes AAAA records from A > > records. The DNS64 function may be implemented in a stub resolver, > > in a recursive resolver, or in an authoritative name server. > > In an authoritative server they do not have to be synthesized. In that case, it's not DNS64. We actually suggest later in the document that you should not use DNS64 on the authoritative server, and that you should instead populate the real zone with the relevant records if you're planning to use NAT64. Is this not clear? > > 5.1.2. The answer when there is an error > > > > Maybe a reference to 5.1.6/5.1.7 (see below) here. Ok. > > 5.1.4. Special exclusion set for AAAA records > > This section is confusing, as other 5.1.* sections are alternatives. I.e. "issue an AAAA query, and do the following if this happens". Specifically as 5.1.4 is before 5.1.6 which is another alternative parallel to for example 5.1.2. > > I.e. I think it would be better if the document was like this (not critical though): > > 5. Behaviour > > 5.1. Queries for AAAA > > Issue a query for AAAA, and behave like the following: > > 5.1.1. A non-empty answer section, where the AAAA is not in the special range > > 5.1.2. A non-empty answer section, where the AAAA is in the special range > > 5.1.3. A non-empty answer section, with CNAME or DNAME > > 5.1.4. An answer with Errcode 3 > > 5.1.5. Other errcodes > > I.e. like a flowchart. One of the subsections matches. That makes it easier to know what to do and how to implement. Ok. To do this, I think, we'd need to take it back to the WG and through LC again, no? That's a pretty significant change. > > > 5.1.6. Data for the answer when performing synthesis > : > > 5.1.7. Performing the synthesis > > 5.1.6 and 5.1.7 should really be merged, and the section should be "errcode != 3 and an empty answer section" > Why? These are strictly speaking distinct steps. After all, if you wanted to populate your authoritative zone with DNS data that would cause a NAT64 to be used, you'd want the output from 5.1.6 but not 5.1.7, right? > > o The TTL field is set to the minimum of the TTL of the original A > > RR and the SOA RR for the queried domain. (Note that in order to > > obtain the TTL of the SOA RR, the DNS64 does not need to perform a > > new query, but it can remember the TTL from the SOA RR in the > > negative response to the AAAA query. If the SOA RR was not > > delivered with the negative response to the AAAA query, then the > > DNS64 SHOULD use a default value of 600 seconds. > > Not really...it should be the smallest of 600 and the TTL for the A, right? Oh, good catch. > > > It is possible > > instead to query explicitly for the SOA RR and use the result of > > that query, but this will increase query load and time to > > resolution for little additional benefit.) This is in keeping > > with the approach used in negative caching ([RFC2308] > > Why not just stop after saying it should be the smallest of the TTL of the A and the SOA, and then let the rest be up to the implementor? I am nervous over more "fixed default values" for negative caching. If the SOA was not returned, then the DNS64 have to query for it. > I felt the same way, but the WG (and Mark Andrews in particular) was quite sure we needed a default. > > o The RDLENGTH field is set to 16 > > > > o The RDATA field is set to the IPv6 representation of the IPv4 > > address from the RDATA field of the A record. The DNS64 SHOULD > > check each A RR against configured IPv4 address ranges and select > > the corresponding IPv6 prefix to use in synthesizing the AAAA RR. > > Why only a SHOULD? And, is this not an implementation issue? Someone wanted to be able to short-circuit this check if there's only one address range configured. > > 5.1.8. Querying in parallel > > > > The DNS64 MAY perform the query for the AAAA RR and for the A RR in > > parallel, in order to minimize the delay. However, this would result > > in performing unnecessary A RR queries in the case where no AAAA RR > > synthesis is required. > > Why is this "however" listed in a normative specification? Well, I think the entire option for querying in parallel ought not to be allowed, on DNS performance grounds, but the web people keep insisting that they need this to achieve acceptable speed. I'm willing to tear it out, but I'd actually like to recommend against such parallel querying. > > There is nothing in 5.1 (what to do when querying for AAAA records) about the additional or authoritative section. No, because that's dealt with in 5.3. Why should it be in 5.1? > > 5.2. Generation of the IPv6 representations of IPv4 addresses > > Should not queries for other RR Types be in 5.2, and this be part of the "synthesizing responses" above, or some other section? > Why? > > 5.3. Handling other Resource Records and the Additional Section > > > > 5.3.1. PTR Resource Record > > > > If a DNS64 server receives a PTR query for a record in the IP6.ARPA > > domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the > > address portion of the QNAME according to the encoding scheme > > outlined in section 2.5 of [RFC3596], and examine the resulting > > address to see whether its prefix matches any of the locally- > > configured Pref64::/n. > > ...or the default well known prefix (that was not to be configured). Good catch, thanks. > > > There are two alternatives for a DNS64 server > > What about DNS64 resolvers that receive PTR queries? Hrm. Yes, I guess that needs to be "There are two alternatives for DNS64 to. . ." > > 2. The second option is for the DNS64 nameserver to synthesize a > > CNAME mapping the IP6.ARPA namespace to the corresponding IN- > > ADDR.ARPA name. > > Is this safe? I.e. it is clear no other RR Type than PTR exists with this owner? > > See Apple Bonjour for example. I agree. This option is only there because Mark Andrews insisted it be. I think the whole thing is a bad idea: you should follow option 1, which is the only safe response IMO. But the WG seemed to want option 2 as well. > A query for a PTR record might not have owner in the IP6.ARPA, so 5.3.1 is really for PTR records in the IP6.ARPA domain. What about other PTR queries? > > I guess the answer is here: > > > If the address prefix does not match any Pref64::/n, then the DNS64 > > server MUST process the query as though it were any other query; i.e. > > a recursive nameserver MUST attempt to resolve the query as though it > > were any other (non-A/AAAA) query, and an authoritative server MUST > > respond authoritatively or with a referral, as appropriate. Yes. > No other RR Types need special treatment? No other RR types need treatment like PTRs do. > I.e. the flow is weird here as well in the document. Because other RR Types comes as 5.3.3. Do you want us to swap that with 5.3.2? > > > 5.3.2. Handling the additional section > > > > DNS64 synthesis MUST NOT be performed on any records in the > > additional section of synthesized answers. The DNS64 MUST pass the > > additional section unchanged. > > The normative part of 5.3.2 should stop here. Remove the rest or move to non-normative section of this document. > Ok. > > 5.4. Assembling a synthesized response to a AAAA query > > Here we have some text on how to do synthesis again? No, this is not how to do synthesis. This is how to assemble the response (i.e. the thing you're going to ship back). The _synthesis_, strictly speaking, was just the creation of the AAAA record from the A, and that goes into an answer section. That answer section is now one of the pieces assembled to make a DNS response packet. > > 5.5. DNSSEC processing: DNS64 in recursive resolver mode > > > > We consider the case where a recursive resolver that is performing > > DNS64 also has a local policy to validate the answers according to > > the procedures outlined in [RFC4035] Section 5. We call this general > > case vDNS64. > > Then this is really: > > 5.5. DNSSEC processing: DNS64 in validating recursive resolver Oh, good catch. Thanks. > > 2. If CD is not set and DO is set, then vDNS64 SHOULD perform > > validation. Whenever vDNS64 performs validation, it MUST > > validate the negative answer for AAAA queries before proceeding > > to query for A records for the same name, in order to be sure > > that there is not a legitimate AAAA record on the Internet. > > Failing to observe this step would allow an attacker to use DNS64 > > as a mechanism to circumvent DNSSEC. If the negative response > > validates, and the response to the A query validates, then the > > vDNS64 MAY perform synthesis and SHOULD set the AD bit in the > > answer to the client. This is acceptable, because [RFC4035], > > section 3.2.3 says that the AD bit is set by the name server side > > of a security-aware recursive name server if and only if it > > considers all the RRSets in the Answer and Authority sections to > > be authentic. In this case, the name server has reason to > > believe the RRSets are all authentic, so it SHOULD set the AD > > bit. If the data does not validate, the vDNS64 MUST respond with > > RCODE=2 (Server failure). > > A security-aware end point might take the presence of the AD bit > > as an indication that the data is valid, and may pass the DNS > > (and DNSSEC) data to an application. If the application attempts > > to validate the synthesized data, of course, the validation will > > fail. One could argue therefore that this approach is not > > desirable, but security aware stub resolvers must not place any > > reliance on data received from resolvers and validated on their > > behalf without certain criteria established by [RFC4035], section > > 4.9.3. An application that wants to perform validation on its > > own should use the CD bit. > > Too much discussion. And (for example) last sentence have "should" in lower case. What does that imply? > It implies that different people have read DNSSECbis and come to different conclusions about whether the AD bit means anything. Rob Austein and some of the other document editors, as well as several other people, are sure that the _only_ way to trust the answer is to set CD and check yourself. But one of the largest vendors out there seems to have decided that the AD bit is significant and useful. This text was the compromise we were able to come up with. I think the "too much discussion" is a suggestion that the second paragraph be moved to a non-normative section? (I'm just trying to be sure what you thought was discussion there.) > > 3. If the CD bit is set and DO is set, then vDNS64 MAY perform > > validation, but MUST NOT perform synthesis. It MUST return the > > data to the query initiator, just like a regular recursive > > resolver, and depend on the client to do the validation and the > > synthesis itself. > > The disadvantage to this approach is that an end point that is > > translation-oblivious but security-aware and validating will not > > be able to use the DNS64 functionality. In this case, the end > > point will not have the desired benefit of NAT64. In effect, > > this strategy means that any end point that wishes to do > > validation in a NAT64 context must be upgraded to be translation- > > aware as well. > > (Re)move second paragraph. Ok. But you agree with this approach? This point is in fact exactly what the DISCUSS on this draft was about: the document assumes that a validating resolver knows how to do DNS64 or else DNS64 just doesn't work for that host. You don't think that's impractical? (That was the question.) > > 8. Security Considerations > > > > DNS64 operates in combination with the DNS, and is therefore subject > > to whatever security considerations are appropriate to the DNS mode > > in which the DNS64 is operating (i.e. authoritative, recursive, or > > stub resolver mode). > > > > DNS64 has the potential to interfere with the functioning of DNSSEC, > > because DNS64 modifies DNS answers, and DNSSEC is designed to detect > > such modification and to treat modified answers as bogus. See the > > discussion above in Section 3, Section 5.5, and Section 6.2. > > It should be noted what might happen if the translator between IPv4 and IPv6 is not in sync with this box. > You mean, if the DNS64 has the wrong Pref::/64 configured, like? > Additionally: > > There is no text on how to handle the query and additional section of the request/response. Sure there is. Section 5.3.2 explicitly says that you may not muck with the additional section, and section 5.4 says you copy the question from the original query. The additional and authority sections are similarly copied from the real DNS answer. Or am I missing something you'd like to see? Thanks for the review! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Fri Aug 20 11:18:05 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5242C3A6B2A for ; Fri, 20 Aug 2010 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24WSnDnuIrsp for ; Fri, 20 Aug 2010 11:18:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7DA7C3A6B0F for ; Fri, 20 Aug 2010 11:18:04 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8C5221ECB408 for ; Fri, 20 Aug 2010 18:18:38 +0000 (UTC) Date: Fri, 20 Aug 2010 14:18:36 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100820181836.GI96071@shinkuro.com> References: <3E7F88FF-7C90-47BE-9B5A-16F3021DFF95@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7F88FF-7C90-47BE-9B5A-16F3021DFF95@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] directorate review of draft-ietf-mif-problem-statement X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:18:05 -0000 On Fri, Aug 20, 2010 at 07:06:04AM -0400, Ralph Droms wrote: > I would appreciate a quick review of draft-ietf-mif-problem-statement. The section relevant to DNS is pretty short. I'd like to confirm that the issues in section 4.1 are correct and clearly framed. Thanks... > I read it. It seems ok to me. There are two interesting implications to the way the text is written. First, this is an implicit recognition that the DNS namespace is not actually a single, unified namespace. I think that's just acknowledging the facts in the world, but I know there are people opposed to that. Second, it seems to be setting up the mif WG to be trying to "solve" the DNS split-views problem. I think this effectively means that we're (i.e. the dns-dir crowd) will need to keep on top of MIF. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Fri Aug 20 11:39:32 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F953A6B2A for ; Fri, 20 Aug 2010 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7O496X-tCyV for ; Fri, 20 Aug 2010 11:39:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 668043A6AFC for ; Fri, 20 Aug 2010 11:39:27 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7KIe1sP067268 for ; Fri, 20 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 20 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100820_184001_051501.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-hip-rfc4423-bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:39:32 -0000 Count: 31 Network Working Group R. Moskowitz Internet-Draft ICSA labs Obsoletes: 4423 (if approved) August 17, 2010 Intended status: Standards Track Expires: February 18, 2011 Host Identity Protocol Architecture draft-ietf-hip-rfc4423-bis-00 Abstract This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. From ogud@ogud.com Fri Aug 20 11:39:32 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1723A6B23 for ; Fri, 20 Aug 2010 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALFtdw2U9dRO for ; Fri, 20 Aug 2010 11:39:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 00E0C3A69E8 for ; Fri, 20 Aug 2010 11:39:26 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7KIe1Aw067237 for ; Fri, 20 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 20 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100820_184001_028562.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-barnes-xmpp-dna-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:39:32 -0000 Count: 62 Internet Engineering Task Force R. Barnes Internet-Draft BBN Technologies Intended status: Standards Track August 19, 2010 Expires: February 20, 2011 Domain Name Assertions draft-barnes-xmpp-dna-00.txt Abstract Many Internet applications allow service delegation via the DNS. However, in the absence of DNSSEC, these delegations are unauthenticated, so clients have to authenticate the delegate as if he were the original service. This situation causes several operational problems. This document describes a mechanism for clients to discover and validate information that authenticates DNS- based service delegations, without relying on the global deployment of DNSSEC. From ogud@ogud.com Sat Aug 21 11:39:34 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8183A69A2 for ; Sat, 21 Aug 2010 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obr4zSrnqKG4 for ; Sat, 21 Aug 2010 11:39:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 02F743A6966 for ; Sat, 21 Aug 2010 11:39:27 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7LIe0nR074991 for ; Sat, 21 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 21 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100821_184000_057925.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-hip-rfc5205-bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 18:39:34 -0000 Count: 77 Network Working Group J. Laganier Internet-Draft QUALCOMM Inc. Obsoletes: 5205 (if approved) August 20, 2010 Intended status: Standards Track Expires: February 21, 2011 Host Identity Protocol (HIP) Domain Name System (DNS) Extension draft-ietf-hip-rfc5205-bis-00 Abstract This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). From ogud@ogud.com Sat Aug 21 11:39:35 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F3E3A6966 for ; Sat, 21 Aug 2010 11:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.241 X-Spam-Level: X-Spam-Status: No, score=-102.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 322mDAqyMnSm for ; Sat, 21 Aug 2010 11:39:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 02FD63A697D for ; Sat, 21 Aug 2010 11:39:27 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7LIe1W3075031 for ; Sat, 21 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 21 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100821_184001_025449.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-arkko-ipv6-transition-guidelines-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 18:39:35 -0000 Count: 10 Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational F. Baker Expires: February 21, 2011 Cisco Systems August 20, 2010 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment draft-arkko-ipv6-transition-guidelines-05 Abstract The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and recommends ones that have been found to work well in operational networks in many common situations. From paf@cisco.com Mon Aug 23 07:43:25 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1116E3A6A53 for ; Mon, 23 Aug 2010 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzkYRbUIRdUT for ; Mon, 23 Aug 2010 07:43:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D3B123A6A3F for ; Mon, 23 Aug 2010 07:43:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIYmckxAZnwN/2dsb2JhbACgLnGfUJtIhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150889131" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 14:43:34 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NEhWjx009860; Mon, 23 Aug 2010 14:43:33 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100820173329.GF96071@shinkuro.com> Date: Mon, 23 Aug 2010 16:43:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> <20100820173329.GF96071@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: Suzanne Woolf , draft-ietf-behave-dns64@tools.ietf.org, IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:43:25 -0000 [copying also Suzanne that had some questions] On 20 aug 2010, at 19.33, Andrew Sullivan wrote: > Hi Patrik, >=20 > Thanks for your detailed review. The document is now under IESG > control, so I can make some suggestions but I can't actually make any > of these changes yet. See below inline. I of course do understand that we at this late stage rather want to have = the document released than pushing it back to the WG. I have tried to = explain below what things I do though absolutely would like to have = clarified and not. And yes, you and I seems to be on the same wavelength = here. > On Thu, Aug 19, 2010 at 11:28:22AM +0200, Patrik F=E4ltstr=F6m wrote: >>> of one or more DNS64-enabled name servers. However, some advanced >>> features require performing the DNS64 function directly in the end- >>> hosts themselves. >>=20 >> I do not like words like "advanced" in texts like these. Why is for = example "validation of DNSSEC records in the end host resolver" to be = "advanced"? >>=20 >=20 > So if we just remove it, that'd be ok? Yes. I.e. do not do any judgement. And specifically for DNSSEC, that is = something people should not be scared away from, which they might be = with text like this. "Oh no, advanced stuff, costs $$$." >> In the non-normative section, the following important information = exists: >>=20 >>> (NOTE: By IPv6-only hosts we mean hosts running IPv6-only >>> applications, hosts that can only use IPv6, as well as cases where >>> only IPv6 connectivity is available to the client. By IPv4-only >>> servers we mean servers running IPv4-only applications, servers = that >>> can only use IPv4, as well as cases where only IPv4 connectivity is >>> available to the server). >=20 > We could restate this in the definitions section. Ok? I think that would be good. >>> 3. Background to DNS64-DNSSEC interaction >>=20 >> As section 2 explicitly is non-normative, is section 3 normative as = it is not say that it is not? >=20 > You raise this several times. I think you're right. I suggest that > we alter the Introduction and state there explicitly which sections > are normative and which not. Ok? What I think you should do is one of two things: 1. In the introduction mention what is normative and not, and then = remove that text from the various sections. 2. Add in each section a word, text etc on the status of that section. = But do it the same way in every section. I think (1) is the best. Be consistent. >> I think personally it would be better to, for each of the = alternatives, compare the DNS64 impact on resolver and server than list = (again) a more comprehensive DNSSEC behaviour list like this. But that = is a personal opinion. >=20 > Well, this was intended to be explanatory material for someone who was > implementing this but not familiar with DNSSEC. Otherwise I was > nervous that the reasoning behind not synthesizing when CD=3D1 = wouldn't > be clear. Ok. Fair. >>> 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query = with >>> the DO bit clear. In this case, DNSSEC is not a concern, = because >>> the querying agent does not understand DNSSEC responses. >>=20 >> Should not it be mentioned that the DNS64, if being a DNS64 resolver, = very well can do validation of the response, and act according to local = policy? Similar to a case 5, but with local policy? >=20 > We can if you like, sure. Yes please. The way I read the text above it says that for the resolver = "DNSSEC is not a concern", which might be read as if the resolver is not = to do validation (at all). I can very well envision cases where A buys a = service from B where B runs the DNS64 service (and Nat64) and requires = validation in the resolver. If B now does NOT do validation, I do not = want B to reference this document and say "as you did send DO bit clear, = I ignore DNSSEC completely -- see RFC". >>> 4. A security-aware and non-validating DNS64 receives a query with >>> the DO bit set and the CD bit set. In this case, the resolver = is >>=20 >> What is "resolver" in this sentence? Looks to me that this is written = only for the "DNS64 resolver" cases and not the DNS64 server case? >=20 > Ugh. It does look like we have terminological issues here. I thought > I'd weeded this out in a previous pass, but I think I did it only in > the normative sections, perhaps. Yuck. >=20 > It is indeed supposed to include the DNS64 server case. For reasons > that are not clear to me, some have insisted that a DNS authoritative > server that is doing DNS64 could do so automatically, without anyone > actually provisioning the AAAA records with the Pref::/64. I don't > personally get this use case at all, but people have insisted on it so > it's possible. When I have read this document (this version and older versions) I have = also been confused. I think the DNS64 server case is so special it just = does not make any sense. And, I feel the authoritative server then by = definition is authoritative for the records regardless of whether they = are "configured" or "synthesized on the fly" (whats the difference?). I.e. the whole document could be so extremely more simple of the DNS64 = server case was indeed a special case explained just in a separate = section where it is explained that "if the DNS64 recursive resolver is = indeed authoritative for some zone(s) it is getting queries for, it = should ...". And then have the document ONLY talk about the two resolver cases. But I do see your issue with restructuring "too much". Unfortunately as the document now talk about DNS64 server it just has = to. Otherwise it must go back to the wg. >> Here one say "DNS64 server" and claim that it "modifies" the record. = I do not understand what "modifies" implies at an authoritative server, = as for me whatever comes from an authoritative server is the = authoritative record. There is nothing that is modified. The records = (the AAAA records) can in the case of a DNS64 server very well be signed = AAAA records that are very stable and never changed. I.e. pre-populated = in the zone and not at all something that is synthesized, and signed! >=20 > Remember that strictly speaking the DNS64 is a logical function. So > the name server function in the DNS64 (which is technically speaking > never exposed to anyone) only provides the A record, and the DNS64 > function "modifies" it. Yes but... > I concede that it is a little uncomfortable > to talk like this, but it preserves the logical distinction between an > actual DNS64 server, and a plain DNS server that happens to have in it > AAAA records using the Pref::/64. Does that make sense? Yes, it does make sense. I still do not like it ;-) >>> 5. A security-aware and validating DNS64 node receives a query = with >>=20 >> Here is a new term, DNS64 node. Is that the same as "a DNS64" = earlier, i.e. one of the three cases? I think in reality it is one of = the "DNS64 resolver" cases one talk about here, and not "DNS64 server". >=20 > Yeah, it's a resolver. (A DNS64 authority server never validates.) > We'll have to go through and fix up the terminology to be consistent > with the terminology section. Should not be so hard I think. Just make up your mind. And ensure you = for every case talk about every case. >>> Authoritative server: A DNS server that can answer authoritatively = a >>> given DNS question. >>=20 >> Is "question" the correct term? I ask... >>=20 >> I try to say "Respond authoritatively to a DNS request" but I also = know that some people do think it is a good thing to say query/answer = when it explicitly is a query we talk about. >=20 > If only the DNS geeks had a consistent set of terms, eh? Oh, wait. > I'm also ok with request. Just make up your mind, and ensure you do not get stuck if DNS64 is used = for dynamic updates... Maybe you should just be clear if you talk about = all query types or not? Maybe you are...I do not have the document in = front of me now. I have, honestly, not really been thinking of what happens with DNS64 = and dynamic updates and other non-queries. >>> DNS64: A logical function that synthesizes DNS resource records = (e.g >>> AAAA records containing IPv6 addresses) from DNS resource = records >>> actually contained in the DNS (e.g., A records containing IPv4 >>> addresses). >>=20 >> Does it have to be synthesized? Also if it is a DNS64 server? >=20 > Yes. Ok. I understand that is how it is designed. Mumble... >>> DNS64 recursor: A recursive resolver that provides the DNS64 >>> functionality as part of its operation. This is the same thing = as >>> "DNS64 in recursive resolver mode". >>=20 >> Above, in the non-normative section, this was called "DNS64 resolver" = as well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, = should not "DNS64 stub" also be defined? >=20 > I don't think we have anywhere in the document where we really needed > a DNS64 stub definition, so I removed it. But I'm happy to add it > back if you think it helps. Dave Thaler in particular was keen that > we not define additional terms we don't strictly need. No, I do not think we should have more terms. My point was that it was called "DNS64 resolver" and here you have = "DNS64 recursor". Below you talk about "stub resolver" and "recursive = resolver", above "recursor". >>> DNS64 resolver: Any resolver (stub resolver or recursive resolver) >>> that provides the DNS64 function. >>>=20 >>> DNS64 server: Any server providing the DNS64 function. >>=20 >> Authoritative server, or also resolvers? >=20 > Any server. So it could be a recursive resolver, yes. This means > that such a beast would be both a DNS64 server and a DNS64 resolver. > That's consistent with the dual name of recursive servers/recursive > resolvers in plain DNS, though, no? Yes. I do think you try to define things like this: DNS64 recursive resolver DNS64 stub resolver DNS64 authoritative server DNS64 resolver: DNS recursive resolver + DNS64 stub resolver DNS64 server: DNS recursive resolver + DNS64 authoritative server I.e. ensure you absolutely do have the sets clearly defined, without any = grammar changes in English. Not all readers do understand what = "recursor" is. Is that a new term? >>> Recursive resolver: A DNS server that accepts requests from one >>> resolver, and asks another server (of some description) for the >>> answer on behalf of the first resolver. >>=20 >> Is this the same definition as in other documents? >=20 > Ha! If only 1034 actually defined this. RFC 4033 has this, which is > as close to a definition as we have: >=20 > Security-Aware Recursive Name Server: An entity that acts in both = the > security-aware name server and security-aware resolver roles. A > more cumbersome but equivalent phrase would be "a security-aware > name server that offers recursive service". >=20 > We could follow the same convention, and define recursive resolver as > a system that acts in both name server and resolver modes, and then > we'd need to define name server and resolver. Name server is kind of > defined in 1034 Sec 2.4., as is resolver. The text in 1034 is > sufficiently poor that many people seem to forget that recursive name > servers can end up cached (sometimes without people knowing it), and I > was trying to draw that information out. But maybe this is a poor > place to do so. Mumble...we need a DNS terminology document. Although, we would never = agree on anything in that document... >>> Synthetic RR: A DNS resource record (RR) that is not contained in >>> any zone data file, but has been synthesized from other RRs. An >>> example is a synthetic AAAA record created from an A record. >>=20 >> Mumble, is "zone data file" a good wording? Should one not talk about = "generated on request" instead? Maybe it is the best wording? Although = some records might be in a database, and not at all in a file. >=20 > Yeah, I originally had just "any zone data", and someone insisted that > wasn't good enough because the synthetic RR could be in a cache > somewhere. (For the same reason, "generated on request" won't exactly > work either.) What about this: >=20 > Synthetic RR: A DNS resource record (RR) that is not contained in > the authoritative servers' zone data, but which is instead > sythesized from other RRs in the same zone. An example is a > synthetic AAAA record created from an A record. >=20 > ? Yes, much better. Thanks. That include all RR that are generated. Not only the ones that are = generated on request. >>> DNS64 is a logical function that synthesizes AAAA records from A >>> records. The DNS64 function may be implemented in a stub resolver, >>> in a recursive resolver, or in an authoritative name server. >>=20 >> In an authoritative server they do not have to be synthesized. >=20 > In that case, it's not DNS64. We actually suggest later in the > document that you should not use DNS64 on the authoritative server, > and that you should instead populate the real zone with the relevant > records if you're planning to use NAT64. Is this not clear? It is. Comments to some degree end up like this if one read detailed = review in a one-pass-process. >>> 5.1.2. The answer when there is an error >>>=20 >>=20 >> Maybe a reference to 5.1.6/5.1.7 (see below) here. >=20 > Ok. >=20 >>> 5.1.4. Special exclusion set for AAAA records >>=20 >> This section is confusing, as other 5.1.* sections are alternatives. = I.e. "issue an AAAA query, and do the following if this happens". = Specifically as 5.1.4 is before 5.1.6 which is another alternative = parallel to for example 5.1.2. >>=20 >> I.e. I think it would be better if the document was like this (not = critical though): >>=20 >> 5. Behaviour >>=20 >> 5.1. Queries for AAAA >>=20 >> Issue a query for AAAA, and behave like the following: >>=20 >> 5.1.1. A non-empty answer section, where the AAAA is not in the = special range >>=20 >> 5.1.2. A non-empty answer section, where the AAAA is in the special = range >>=20 >> 5.1.3. A non-empty answer section, with CNAME or DNAME >>=20 >> 5.1.4. An answer with Errcode 3 >>=20 >> 5.1.5. Other errcodes >>=20 >> I.e. like a flowchart. One of the subsections matches. That makes it = easier to know what to do and how to implement. >=20 > Ok. To do this, I think, we'd need to take it back to the WG and > through LC again, no? That's a pretty significant change. Do not do the change. But you do understand my view? I.e. have the sections like a flowchart. 1. DNS64 server that receives a query for AAAA 1.1. Issue query for AAAA 1.1.1. If RR Code is zero 1.1.2. If RR Code is non-zero 1.2. Issue query for A 1.2.1. If RR Code is zero 1.2.2. If RR Code is non-zero 2. DNS64 server that receives a query for PTR 3. DNS64 server that receives a query for other RR Types 4. Synthezising responses Etc... Then one can do section 1 and 2 and 3, follow step by step, and then get = references to section 4, 5 etc as subroutines. As it is now the = flowchart is sort of mixed with "think of this if the errcode is..." or = "this is how you synthesizes a record". Next version of the document. >>> 5.1.6. Data for the answer when performing synthesis >> : >>> 5.1.7. Performing the synthesis >>=20 >> 5.1.6 and 5.1.7 should really be merged, and the section should be = "errcode !=3D 3 and an empty answer section" >=20 > Why? These are strictly speaking distinct steps. After all, if you > wanted to populate your authoritative zone with DNS data that would > cause a NAT64 to be used, you'd want the output from 5.1.6 but not > 5.1.7, right? Explanation to my view: It might be confusing for the reader to = understand that it should do more than one subsection of 5.1 but still = not all of them. I.e. the way I like documents, subsections should = either all of them be used, or only one, and in the latter case, the = header (or first paragraph) should clearly have a requirement or test = that should evaluate to TRUE if the section is to be used. But ok... I see your way of looking at it. >>> o The TTL field is set to the minimum of the TTL of the original A >>> RR and the SOA RR for the queried domain. (Note that in order = to >>> obtain the TTL of the SOA RR, the DNS64 does not need to perform = a >>> new query, but it can remember the TTL from the SOA RR in the >>> negative response to the AAAA query. If the SOA RR was not >>> delivered with the negative response to the AAAA query, then the >>> DNS64 SHOULD use a default value of 600 seconds. >>=20 >> Not really...it should be the smallest of 600 and the TTL for the A, = right? >=20 > Oh, good catch. Yeah! One good catch! :-D >>> It is possible >>> instead to query explicitly for the SOA RR and use the result of >>> that query, but this will increase query load and time to >>> resolution for little additional benefit.) This is in keeping >>> with the approach used in negative caching ([RFC2308] >>=20 >> Why not just stop after saying it should be the smallest of the TTL = of the A and the SOA, and then let the rest be up to the implementor? I = am nervous over more "fixed default values" for negative caching. If the = SOA was not returned, then the DNS64 have to query for it. >=20 > I felt the same way, but the WG (and Mark Andrews in particular) was > quite sure we needed a default. Hmm...ok. >>> o The RDLENGTH field is set to 16 >>>=20 >>> o The RDATA field is set to the IPv6 representation of the IPv4 >>> address from the RDATA field of the A record. The DNS64 SHOULD >>> check each A RR against configured IPv4 address ranges and = select >>> the corresponding IPv6 prefix to use in synthesizing the AAAA = RR. >>=20 >> Why only a SHOULD? And, is this not an implementation issue? >=20 > Someone wanted to be able to short-circuit this check if there's only > one address range configured. Well, then it is really checking every IPv4 A still, right? The check = always returns the one same IPv6 prefix. Mumble. I am really nervous there will not be a test here in some = implementations. I.e. that someone will screw up. Ok, I do know the = meaning of SHOULD, but still... >>> 5.1.8. Querying in parallel >>>=20 >>> The DNS64 MAY perform the query for the AAAA RR and for the A RR in >>> parallel, in order to minimize the delay. However, this would = result >>> in performing unnecessary A RR queries in the case where no AAAA RR >>> synthesis is required. >>=20 >> Why is this "however" listed in a normative specification? >=20 > Well, I think the entire option for querying in parallel ought not to > be allowed, on DNS performance grounds, but the web people keep > insisting that they need this to achieve acceptable speed. I'm > willing to tear it out, but I'd actually like to recommend against > such parallel querying. No, ok, let it be there. I am just *personally* very tired of long RFC with lots of text (that = you give to programmers and they do not get it). This document is good in that it have normative and non-normative stuff, = and the normative stuff is in reality very small. But one need lots of = explanations. Right? FWIW, I have myself inside Cisco written a DNS64 thing that is shorter = regarding "what to do", but have lots of explanations... Some people that implement stuff does not have to know what to do, and = if they really want to, they can read the explanatory stuff. But, that is also one of my windmills in the IETF that I am fighting. Shorter documents! Just write what is needed in the normative section. = When you can not remove a single word more, you are done. That said, long explanations, examples and what not. >> There is nothing in 5.1 (what to do when querying for AAAA records) = about the additional or authoritative section. >=20 > No, because that's dealt with in 5.3. Why should it be in 5.1? Ok, sorry, confusion... Let me exaggerate a bit, and show how confusing I find it. I think 5 = should be split in 5 and a new section 6. The new section 6 should = include the subsections of 5 that today is only "support" to the other = subsections. Then titles of the subsections of 5 should be such that one = for each case should read one and only one of the sections. We have: > 5.1 Resolving AAAA queries and the answer section Is this for only AAAA queries, or for AAAA queries and answer section = for query for any RR Type? Then we have: > 5.2. Generation of the IPv6 representations of IPv4 addresses Is this for AAAA queries, or all queries? We have already walked through = how to handle the answer section in 5.1? And then: > 5.3. Handling other Resource Records and the Additional Section What about the Query and Authoritative section? Is this Additional = Section for all RR Types, or just non-AAAA RR? And then: > 5.4. Assembling a synthesized response to a AAAA query Is this a subsection of? When should I read this? AAAA query, but that = was 5.1, or? And then last: > 5.5. DNSSEC processing: DNS64 in recursive resolver mode Is this not DNS64 resolver mode in general? >>> 5.2. Generation of the IPv6 representations of IPv4 addresses >>=20 >> Should not queries for other RR Types be in 5.2, and this be part of = the "synthesizing responses" above, or some other section? >=20 > Why? Because that is the only case when this does happen? >>> 5.3. Handling other Resource Records and the Additional Section >>>=20 >>> 5.3.1. PTR Resource Record >>>=20 >>> If a DNS64 server receives a PTR query for a record in the IP6.ARPA >>> domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse = the >>> address portion of the QNAME according to the encoding scheme >>> outlined in section 2.5 of [RFC3596], and examine the resulting >>> address to see whether its prefix matches any of the locally- >>> configured Pref64::/n. >>=20 >> ...or the default well known prefix (that was not to be configured). >=20 > Good catch, thanks. :-) >>> There are two alternatives for a DNS64 server >>=20 >> What about DNS64 resolvers that receive PTR queries? >=20 > Hrm. Yes, I guess that needs to be "There are two alternatives for = DNS64 to. . ." Thanks. >>> 2. The second option is for the DNS64 nameserver to synthesize a >>> CNAME mapping the IP6.ARPA namespace to the corresponding IN- >>> ADDR.ARPA name. >>=20 >> Is this safe? I.e. it is clear no other RR Type than PTR exists with = this owner? >>=20 >> See Apple Bonjour for example. >=20 > I agree. This option is only there because Mark Andrews insisted it > be. I think the whole thing is a bad idea: you should follow option > 1, which is the only safe response IMO. But the WG seemed to want > option 2 as well. But this is wrong as the PTR might not have a corresponding IN-ADDR.ARPA = name. In that case you absolutely must say "....to the corresponding = name". Or "...to the corresponding name in IN-ADDR.ARPA if it exists". Lets say we have: www.example.com. IN PTR foo.bar.example. Now we query for that....I think the text must absolutely be so that the = PTR in question is not invalid. >> A query for a PTR record might not have owner in the IP6.ARPA, so = 5.3.1 is really for PTR records in the IP6.ARPA domain. What about other = PTR queries? >>=20 >> I guess the answer is here: >>=20 >>> If the address prefix does not match any Pref64::/n, then the DNS64 >>> server MUST process the query as though it were any other query; = i.e. >>> a recursive nameserver MUST attempt to resolve the query as though = it >>> were any other (non-A/AAAA) query, and an authoritative server MUST >>> respond authoritatively or with a referral, as appropriate. >=20 > Yes. Good. >> No other RR Types need special treatment? >=20 > No other RR types need treatment like PTRs do.=20 Good. >> I.e. the flow is weird here as well in the document. Because other RR = Types comes as 5.3.3. >=20 > Do you want us to swap that with 5.3.2? No. See above. I think I talk about a larger restructuring in the next = version of the document. >>> 5.3.2. Handling the additional section >>>=20 >>> DNS64 synthesis MUST NOT be performed on any records in the >>> additional section of synthesized answers. The DNS64 MUST pass the >>> additional section unchanged. >>=20 >> The normative part of 5.3.2 should stop here. Remove the rest or move = to non-normative section of this document. >=20 > Ok. Once again. See above. Do not do the change. >>> 5.4. Assembling a synthesized response to a AAAA query >>=20 >> Here we have some text on how to do synthesis again? >=20 > No, this is not how to do synthesis. This is how to assemble the > response (i.e. the thing you're going to ship back). The _synthesis_, > strictly speaking, was just the creation of the AAAA record from the > A, and that goes into an answer section. That answer section is now > one of the pieces assembled to make a DNS response packet. Ok... >>> 5.5. DNSSEC processing: DNS64 in recursive resolver mode >>>=20 >>> We consider the case where a recursive resolver that is performing >>> DNS64 also has a local policy to validate the answers according to >>> the procedures outlined in [RFC4035] Section 5. We call this = general >>> case vDNS64. >>=20 >> Then this is really: >>=20 >> 5.5. DNSSEC processing: DNS64 in validating recursive resolver >=20 > Oh, good catch. Thanks. :-) >>> 2. If CD is not set and DO is set, then vDNS64 SHOULD perform >>> validation. Whenever vDNS64 performs validation, it MUST >>> validate the negative answer for AAAA queries before proceeding >>> to query for A records for the same name, in order to be sure >>> that there is not a legitimate AAAA record on the Internet. >>> Failing to observe this step would allow an attacker to use = DNS64 >>> as a mechanism to circumvent DNSSEC. If the negative response >>> validates, and the response to the A query validates, then the >>> vDNS64 MAY perform synthesis and SHOULD set the AD bit in the >>> answer to the client. This is acceptable, because [RFC4035], >>> section 3.2.3 says that the AD bit is set by the name server = side >>> of a security-aware recursive name server if and only if it >>> considers all the RRSets in the Answer and Authority sections = to >>> be authentic. In this case, the name server has reason to >>> believe the RRSets are all authentic, so it SHOULD set the AD >>> bit. If the data does not validate, the vDNS64 MUST respond = with >>> RCODE=3D2 (Server failure). >>> A security-aware end point might take the presence of the AD = bit >>> as an indication that the data is valid, and may pass the DNS >>> (and DNSSEC) data to an application. If the application = attempts >>> to validate the synthesized data, of course, the validation = will >>> fail. One could argue therefore that this approach is not >>> desirable, but security aware stub resolvers must not place any >>> reliance on data received from resolvers and validated on their >>> behalf without certain criteria established by [RFC4035], = section >>> 4.9.3. An application that wants to perform validation on its >>> own should use the CD bit. >>=20 >> Too much discussion. And (for example) last sentence have "should" in = lower case. What does that imply? >=20 > It implies that different people have read DNSSECbis and come to > different conclusions about whether the AD bit means anything. Hmm... > Rob > Austein and some of the other document editors, as well as several > other people, are sure that the _only_ way to trust the answer is to > set CD and check yourself. But one of the largest vendors out there > seems to have decided that the AD bit is significant and useful. This > text was the compromise we were able to come up with. Ok. Fair. > I think the "too much discussion" is a suggestion that the second > paragraph be moved to a non-normative section? (I'm just trying to be > sure what you thought was discussion there.) Or just let it be. But you are right in general. >>> 3. If the CD bit is set and DO is set, then vDNS64 MAY perform >>> validation, but MUST NOT perform synthesis. It MUST return the >>> data to the query initiator, just like a regular recursive >>> resolver, and depend on the client to do the validation and the >>> synthesis itself. >>> The disadvantage to this approach is that an end point that is >>> translation-oblivious but security-aware and validating will = not >>> be able to use the DNS64 functionality. In this case, the end >>> point will not have the desired benefit of NAT64. In effect, >>> this strategy means that any end point that wishes to do >>> validation in a NAT64 context must be upgraded to be = translation- >>> aware as well. >>=20 >> (Re)move second paragraph. >=20 > Ok. Oh, I see...now... Hmm...leave it. > But you agree with this approach? This point is in fact exactly > what the DISCUSS on this draft was about: the document assumes that a > validating resolver knows how to do DNS64 or else DNS64 just doesn't > work for that host. You don't think that's impractical? (That was > the question.) Let me think...you talk about the case when a resolver that has only = IPv6 transport want to use a DNS64 service somewhere where the DNS64 is = NOT doing the validation? But, there will be RR synthesized by the DNS64 = box, so that must do the validation, right? This actually do work if you have a validating resolver on the inside of = a DNS64 box and that resolver is doing DNS64 by itself. Which I think = should be possible. So you can have one DNS64 be validating and use another DNS64 as a = forwarder. Which I think makes sense. >>> 8. Security Considerations >>>=20 >>> DNS64 operates in combination with the DNS, and is therefore = subject >>> to whatever security considerations are appropriate to the DNS mode >>> in which the DNS64 is operating (i.e. authoritative, recursive, or >>> stub resolver mode). >>>=20 >>> DNS64 has the potential to interfere with the functioning of = DNSSEC, >>> because DNS64 modifies DNS answers, and DNSSEC is designed to = detect >>> such modification and to treat modified answers as bogus. See the >>> discussion above in Section 3, Section 5.5, and Section 6.2. >>=20 >> It should be noted what might happen if the translator between IPv4 = and IPv6 is not in sync with this box. >=20 > You mean, if the DNS64 has the wrong Pref::/64 configured, like? Yes. >> Additionally: >>=20 >> There is no text on how to handle the query and additional section of = the request/response. >=20 > Sure there is. Section 5.3.2 explicitly says that you may not muck > with the additional section, and section 5.4 says you copy the > question from the original query. The additional and authority > sections are similarly copied from the real DNS answer. Or am I > missing something you'd like to see? No, I was missing it. See above. > Thanks for the review! Thanks for the pushing... paf From ogud@ogud.com Mon Aug 23 11:41:02 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B36D3A6A77 for ; Mon, 23 Aug 2010 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kWjAkMIY5+F for ; Mon, 23 Aug 2010 11:40:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A53853A6A8C for ; Mon, 23 Aug 2010 11:39:27 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7NIe0oh091135 for ; Mon, 23 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 23 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100823_184000_012028.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-josefsson-keyassure-tls-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:41:02 -0000 Count: 13 Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Standards Track August 23, 2010 Expires: February 24, 2011 Confirming the Certificate structure in TLS with Secure DNS draft-josefsson-keyassure-tls-00 Abstract TLS supports X.509 and OpenPGP certificate based mechanisms to authenticate a server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certificate authority to have made this association correctly, and an X.509/ OpenPGP implementation to validate that properly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the certificate chain transferred by TLS with the intended domain name. From ajs@shinkuro.com Mon Aug 23 18:39:57 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6382A3A696F for ; Mon, 23 Aug 2010 18:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Vgjoxnr6-k for ; Mon, 23 Aug 2010 18:39:55 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B46483A6B12 for ; Mon, 23 Aug 2010 18:39:55 -0700 (PDT) Received: from crankycanuck.ca (unknown [12.50.90.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3B6C31ECB41D; Tue, 24 Aug 2010 01:40:27 +0000 (UTC) Date: Mon, 23 Aug 2010 21:40:22 -0400 From: Andrew Sullivan To: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= Message-ID: <20100824014021.GA9417@shinkuro.com> References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> <20100820173329.GF96071@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Suzanne Woolf , draft-ietf-behave-dns64@tools.ietf.org, IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 01:39:57 -0000 Hi, On Mon, Aug 23, 2010 at 04:43:32PM +0200, Patrik Fältström wrote: > > I of course do understand that we at this late stage rather want to > have the document released than pushing it back to the WG. I have > tried to explain below what things I do though absolutely would like > to have clarified and not. And yes, you and I seems to be on the > same wavelength here. > Well, there are two views: 1. We should not publish until the spec is totally ready. 2. We should publish a reasonably complete spec at the minimal standards-track level and then do revisions to advance it. Given the standards track rules as they are, I'm in favour of (2). It would appear that the IETF Chair and a number of supporters are not, so maybe we should think twice. Anyway, I'll commit now to starting a dns64-bis document as soon as practical if people think that would be desirable. I've removed in what follows places where it's clear to me what to do. > > On Thu, Aug 19, 2010 at 11:28:22AM +0200, Patrik Fältström wrote: > > I.e. the whole document could be so extremely more simple of the DNS64 server case was indeed a special case explained just in a separate section where it is explained that "if the DNS64 recursive resolver is indeed authoritative for some zone(s) it is getting queries for, it should ...". > > And then have the document ONLY talk about the two resolver cases. > > But I do see your issue with restructuring "too much". > > Unfortunately as the document now talk about DNS64 server it just has to. Otherwise it must go back to the wg. > I think what you're saying here (and in some other remarks about "next version" is what to do when dns64-bis is being prepared, and _not_ what to do with the next version of this draft. Right? > I have, honestly, not really been thinking of what happens with DNS64 and dynamic updates and other non-queries. > Do you think an explicit treatment of what happens with dynamic update is needed? I think I understand it, but I'll bet a pretty good lunch it hasn't been pressed very hard. > Mumble...we need a DNS terminology document. Although, we would never agree on anything in that document... > I merely note without comment the tremendous success the DNSEXT WG met with when hoping to do that job ;-) > > Ok. To do this, I think, we'd need to take it back to the WG and > > through LC again, no? That's a pretty significant change. > > Do not do the change. > > But you do understand my view? > > I.e. have the sections like a flowchart. Yep, I get it. But you want to leave this for dns64-bis, correct? > >>> o The RDATA field is set to the IPv6 representation of the IPv4 > >>> address from the RDATA field of the A record. The DNS64 SHOULD > >>> check each A RR against configured IPv4 address ranges and select > >>> the corresponding IPv6 prefix to use in synthesizing the AAAA RR. > >> > >> Why only a SHOULD? And, is this not an implementation issue? > > > > Someone wanted to be able to short-circuit this check if there's only > > one address range configured. > > Well, then it is really checking every IPv4 A still, right? The check always returns the one same IPv6 prefix. > > Mumble. I am really nervous there will not be a test here in some implementations. I.e. that someone will screw up. Ok, I do know the meaning of SHOULD, but still... I'm willing to ask on the list why this isn't MUST, and to recommend that it be. Ok? > I am just *personally* very tired of long RFC with lots of text (that you give to programmers and they do not get it). > Yes. I think what might help is to add a DISCUSSION heading for these bits of explanatory fluff, and then call out in the introduction (explicitly) that the bits under DISCUSSION are never normative, but are intended to explain the motivation. Thoughts? > >>> 5.2. Generation of the IPv6 representations of IPv4 addresses > >> > >> Should not queries for other RR Types be in 5.2, and this be part of the "synthesizing responses" above, or some other section? > > > > Why? > > Because that is the only case when this does happen? But there's a logical difference between the generation of the v6 representation and the synthesis, since one is just a step in the other, I think? > But this is wrong as the PTR might not have a corresponding IN-ADDR.ARPA name. In that case you absolutely must say "....to the corresponding name". Or "...to the corresponding name in IN-ADDR.ARPA if it exists". > > Lets say we have: > > www.example.com. IN PTR foo.bar.example. > > Now we query for that....I think the text must absolutely be so that the PTR in question is not invalid. Ok, I propose that this be altered so that the synthetic CNAME is returned only if there is existing RDATA at the PTR (i.e. what you said). I'll check on the behave list to make sure there's no objection, but if there is I can't understand what it'd be. > >>> 3. If the CD bit is set and DO is set, then vDNS64 MAY perform > >>> validation, but MUST NOT perform synthesis. It MUST return the > >>> data to the query initiator, just like a regular recursive > >>> resolver, and depend on the client to do the validation and the > >>> synthesis itself. > >>> The disadvantage to this approach is that an end point that is > >>> translation-oblivious but security-aware and validating will not > >>> be able to use the DNS64 functionality. In this case, the end > >>> point will not have the desired benefit of NAT64. In effect, > >>> this strategy means that any end point that wishes to do > >>> validation in a NAT64 context must be upgraded to be translation- > >>> aware as well. > > But you agree with this approach? This point is in fact exactly > > what the DISCUSS on this draft was about: the document assumes that a > > validating resolver knows how to do DNS64 or else DNS64 just doesn't > > work for that host. You don't think that's impractical? (That was > > the question.) > > Let me think...you talk about the case when a resolver that has only IPv6 transport want to use a DNS64 service somewhere where the DNS64 is NOT doing the validation? But, there will be RR synthesized by the DNS64 box, so that must do the validation, right? > > This actually do work if you have a validating resolver on the inside of a DNS64 box and that resolver is doing DNS64 by itself. Which I think should be possible. > > So you can have one DNS64 be validating and use another DNS64 as a forwarder. > > Which I think makes sense. Well, something like that, yes. But the main thing is this: an existing, shipping-today, validating resolver that is DNS64 oblivious and that goes into a DNS64-dependent network (i.e. one with a NAT64) will simply break. I think that is better than the alternative (i.e. "screw with DNSSEC so that the NAT64 works anyway"), and anyway I have no idea how to make that alternative work. But the DISCUSS on this document was originally that it is unrealistic to accept that. I think it's early enough days in end-point validation that the only people we'll inconvenience are the early-upgrading DNSSEC nerds, but I could be wrong. What do you (or any of the rest of the DNS directorate, or even anyone else who's listening!) think? Again, thanks lots for the detailed review. You know, however, that this means I'm going to hassle you about the -bis document, right? :-D A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paf@cisco.com Mon Aug 23 18:59:45 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86BA3A6818 for ; Mon, 23 Aug 2010 18:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.885 X-Spam-Level: X-Spam-Status: No, score=-9.885 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYRsjRzAHUH7 for ; Mon, 23 Aug 2010 18:59:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DF5AC3A680B for ; Mon, 23 Aug 2010 18:59:43 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAELEckxAZnwM/2dsb2JhbACgPXGfeJwJhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,260,1280707200"; d="scan'208";a="150935982" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2010 02:00:16 +0000 Received: from [192.165.72.14] (dhcp-10-61-111-20.cisco.com [10.61.111.20]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7O20F5H000582; Tue, 24 Aug 2010 02:00:16 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100824014021.GA9417@shinkuro.com> Date: Tue, 24 Aug 2010 04:00:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17E5BE77-BA99-4278-9CBD-5246D831A282@cisco.com> References: <20100812144452.GC63338@shinkuro.com> <869C5178-0637-4374-9841-FB5393469C6E@gmail.com> <20100820173329.GF96071@shinkuro.com> <20100824014021.GA9417@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: Suzanne Woolf , draft-ietf-behave-dns64@tools.ietf.org, IETF Directorate DNS Subject: Re: [dns-dir] [tim.polk@nist.gov: DISCUSS: ] X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 01:59:45 -0000 On 24 aug 2010, at 03.40, Andrew Sullivan wrote: > Well, there are two views: >=20 > 1. We should not publish until the spec is totally ready. >=20 > 2. We should publish a reasonably complete spec at the minimal > standards-track level and then do revisions to advance it. >=20 > Given the standards track rules as they are, I'm in favour of (2). It > would appear that the IETF Chair and a number of supporters are not, > so maybe we should think twice. Anyway, I'll commit now to starting a > dns64-bis document as soon as practical if people think that would be > desirable. I agree with you. If we try to make a document "better", then what is = happening is that it takes time. People "fall asleep", and we do not get = good review. So the quality of the document do not always increase... >> Unfortunately as the document now talk about DNS64 server it just has = to. Otherwise it must go back to the wg. >=20 > I think what you're saying here (and in some other remarks about "next > version" is what to do when dns64-bis is being prepared, and _not_ > what to do with the next version of this draft. Right? Absolutely! DNS64-bis >> I have, honestly, not really been thinking of what happens with DNS64 = and dynamic updates and other non-queries. >=20 > Do you think an explicit treatment of what happens with dynamic update > is needed? I think I understand it, but I'll bet a pretty good lunch > it hasn't been pressed very hard. DNS64-bis I just want someone to think about _all_ DNS requests that we have. Not = only normal queries. Thinking of how to handle dynamic updates and DNS64 makes my head hurt = though. >> Mumble...we need a DNS terminology document. Although, we would never = agree on anything in that document... >=20 > I merely note without comment the tremendous success the DNSEXT WG met > with when hoping to do that job ;-) Like in the UN, everything is an outstanding success! ;-) >>> Ok. To do this, I think, we'd need to take it back to the WG and >>> through LC again, no? That's a pretty significant change. >>=20 >> Do not do the change. >>=20 >> But you do understand my view? >>=20 >> I.e. have the sections like a flowchart. >=20 > Yep, I get it. But you want to leave this for dns64-bis, correct? Yes. >>>>> o The RDATA field is set to the IPv6 representation of the IPv4 >>>>> address from the RDATA field of the A record. The DNS64 SHOULD >>>>> check each A RR against configured IPv4 address ranges and = select >>>>> the corresponding IPv6 prefix to use in synthesizing the AAAA = RR. >>>>=20 >>>> Why only a SHOULD? And, is this not an implementation issue? >>>=20 >>> Someone wanted to be able to short-circuit this check if there's = only >>> one address range configured. >>=20 >> Well, then it is really checking every IPv4 A still, right? The check = always returns the one same IPv6 prefix. >>=20 >> Mumble. I am really nervous there will not be a test here in some = implementations. I.e. that someone will screw up. Ok, I do know the = meaning of SHOULD, but still... >=20 > I'm willing to ask on the list why this isn't MUST, and to recommend > that it be. Ok? If you do not think that is "too much" for the wg, please do. I do not want to reopen the document. But I really would like to have = this change. >> I am just *personally* very tired of long RFC with lots of text (that = you give to programmers and they do not get it). >=20 > Yes. I think what might help is to add a DISCUSSION heading for these > bits of explanatory fluff, and then call out in the introduction > (explicitly) that the bits under DISCUSSION are never normative, but > are intended to explain the motivation. Thoughts? Hmm....I think to some degree this document is already much better than = lots of others, simply because it does mark what is normative and not. = Just because we happen to have those markings, do I ask for even more = detailed markings? Maybe. Possibly. Just skip these things. We need this document. And fix the few things that are needed to be = changed. >>>>> 5.2. Generation of the IPv6 representations of IPv4 addresses >>>>=20 >>>> Should not queries for other RR Types be in 5.2, and this be part = of the "synthesizing responses" above, or some other section? >>>=20 >>> Why? >>=20 >> Because that is the only case when this does happen? >=20 > But there's a logical difference between the generation of the v6 > representation and the synthesis, since one is just a step in the > other, I think? I understand that view now. I have not really separated the synthesis = (creation of the records) and building of the actual response (that = might include some synthesized records). So my comments on these things just went *poof*. >> But this is wrong as the PTR might not have a corresponding = IN-ADDR.ARPA name. In that case you absolutely must say "....to the = corresponding name". Or "...to the corresponding name in IN-ADDR.ARPA if = it exists". >>=20 >> Lets say we have: >>=20 >> www.example.com. IN PTR foo.bar.example. >>=20 >> Now we query for that....I think the text must absolutely be so that = the PTR in question is not invalid. >=20 > Ok, I propose that this be altered so that the synthetic CNAME is > returned only if there is existing RDATA at the PTR (i.e. what you > said). I'll check on the behave list to make sure there's no > objection, but if there is I can't understand what it'd be. What is needed to check for is whether the PTR is in IN-ADDR.ARPA. Not = only if there is any RDATA at the PTR. Or? If so, some magic has to = happen. If the PTR is not in IN-ADDR.ARPA, the stuff can be managed like = "every other RR Type", right? Well, you seem to get my point. >>>>> 3. If the CD bit is set and DO is set, then vDNS64 MAY perform >>>>> validation, but MUST NOT perform synthesis. It MUST return = the >>>>> data to the query initiator, just like a regular recursive >>>>> resolver, and depend on the client to do the validation and = the >>>>> synthesis itself. >>>>> The disadvantage to this approach is that an end point that is >>>>> translation-oblivious but security-aware and validating will = not >>>>> be able to use the DNS64 functionality. In this case, the end >>>>> point will not have the desired benefit of NAT64. In effect, >>>>> this strategy means that any end point that wishes to do >>>>> validation in a NAT64 context must be upgraded to be = translation- >>>>> aware as well. >=20 >>> But you agree with this approach? This point is in fact exactly >>> what the DISCUSS on this draft was about: the document assumes that = a >>> validating resolver knows how to do DNS64 or else DNS64 just doesn't >>> work for that host. You don't think that's impractical? (That was >>> the question.) >>=20 >> Let me think...you talk about the case when a resolver that has only = IPv6 transport want to use a DNS64 service somewhere where the DNS64 is = NOT doing the validation? But, there will be RR synthesized by the DNS64 = box, so that must do the validation, right? >>=20 >> This actually do work if you have a validating resolver on the inside = of a DNS64 box and that resolver is doing DNS64 by itself. Which I think = should be possible. >>=20 >> So you can have one DNS64 be validating and use another DNS64 as a = forwarder. >>=20 >> Which I think makes sense. >=20 > Well, something like that, yes. But the main thing is this: an > existing, shipping-today, validating resolver that is DNS64 oblivious > and that goes into a DNS64-dependent network (i.e. one with a NAT64) > will simply break. Oh boy. Yes, I get the point now. > I think that is better than the alternative (i.e. "screw with DNSSEC = so > that the NAT64 works anyway"), and anyway I have no idea how to make > that alternative work. Ok. > But the DISCUSS on this document was > originally that it is unrealistic to accept that. I think it's early > enough days in end-point validation that the only people we'll > inconvenience are the early-upgrading DNSSEC nerds, but I could be > wrong. What do you (or any of the rest of the DNS directorate, or > even anyone else who's listening!) think? I would say the best solution is: When a validating full service resolver is moved behind a Nat64/DNS64 = box, and only get IPv6 transport, then that box to be able to do = validation MUST be configured to do the DNS64 functionality itself. The = DNS64 spec MUST work accordingly, i.e. one should NOT have a hierarchy = of DNS64 boxes, but only one. The existing DNS64 box, that might be set as a forwarder for the newly = placed box on the "inside" of the NAT64/DNS64, should not have to be = reconfigured, but instead be transparent regarding DNS64 if a validating = resolver is sending queries to it. If a validating resolver is set on the inside of a DNS64 box and the = validating resolver is NOT supporting DNS64 with prefix etc according to = the NAT64 in the network it exists, then it will not function properly. > Again, thanks lots for the detailed review. You know, however, that > this means I'm going to hassle you about the -bis document, right? > :-D Yeah, I was nervous about that... ;-) Patrik From ogud@ogud.com Tue Aug 24 11:39:30 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7F33A6829 for ; Tue, 24 Aug 2010 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOz1jdQ52GVp for ; Tue, 24 Aug 2010 11:39:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9235B3A67E6 for ; Tue, 24 Aug 2010 11:39:29 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7OIe1bT000639 for ; Tue, 24 Aug 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 24 Aug 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100824_184001_096902.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-hip-rfc5201-bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 18:39:30 -0000 Count: 14 Network Working Group R. Moskowitz Internet-Draft ICSAlabs Obsoletes: 5201 (if approved) P. Jokela, Ed. Intended status: Standards Track Ericsson Research NomadicLab Expires: February 21, 2011 T. Henderson The Boeing Company August 20, 2010 Host Identity Protocol draft-ietf-hip-rfc5201-bis-00 Abstract This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. From ogud@ogud.com Wed Aug 25 11:39:30 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030E53A67C0 for ; Wed, 25 Aug 2010 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rOU8amA4A9a for ; Wed, 25 Aug 2010 11:39:28 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 789EB3A687F for ; Wed, 25 Aug 2010 11:39:28 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7PIe0a7009636 for ; Wed, 25 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 25 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100825_184000_000395.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-hoffman-keys-linkage-from-dns-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 18:39:30 -0000 Count: 42 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Standards Track J. Schlyter Expires: February 25, 2011 Kirei AB W. Kumari A. Langley Google August 24, 2010 Using Secure DNS to Associate Certificates with Domain Names For TLS draft-hoffman-keys-linkage-from-dns-01 Abstract TLS and DTLS uses certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certificate authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. From ogud@ogud.com Tue Aug 31 11:39:32 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D083A6A53 for ; Tue, 31 Aug 2010 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E-VSBSftwBl for ; Tue, 31 Aug 2010 11:39:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E0B743A6A4A for ; Tue, 31 Aug 2010 11:39:30 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7VIe0Q8063762 for ; Tue, 31 Aug 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 31 Aug 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100831_184000_008090.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-lee-v4v6tran-problem-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 18:39:32 -0000 Count: 12 Operations Area Y. Lee, Ed. Internet-Draft Comcast Intended status: Informational August 30, 2010 Expires: March 3, 2011 Problem Statements of IPv6 Transition of ISP draft-lee-v4v6tran-problem-00 Abstract The IETF has defined a number of technologies and techniques that targets the transition from IPv4 to IPv6. Documented techniques identify high level use cases and generalized options for networks. Operators may have difficulty attempting to apply the documented techniques to their networks since each network and system operates uniquely within the global Internet. Operators may require guidance on how to identify the appropriate technology, or technologies, and apply them to their specific environments. This memo describes the problem statements related to the transition of operator's networks to IPv6.