Re: [v6ops] NAT64/DNS64 and DNSSEC

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 23 July 2015 13:59 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CBC1ACD9B for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 06:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdYLNwGAMZhe for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 06:59:27 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718891ACCF8 for <v6ops@ietf.org>; Thu, 23 Jul 2015 06:59:27 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so209849934wib.0 for <v6ops@ietf.org>; Thu, 23 Jul 2015 06:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XPQaY2Q7sT+uVimmIfV4HAo4ZCvk04+0ZJRuHSvEWrY=; b=UjBe6icQYAhj9sG0auSgwPLR2wCTuiTE+Qkd8WsczaQ4VrVi7cHXxvgzgigF91n0xd RVImaaZiOeNFNLjQB7N5d01p5ke12giJATk8kNxRurBMdQ7G6rrLHKQ/7MWMbS/M4BYh eBovo4KUWO1ZaxImrYbiLFSwqNpiJ+vi6Qqy60+GpSAUKPvVRumDYoRmQnj1/TYJwXQV f+tR52BMVVC+Byda0Evk+zHMEuXAsBvieCmDRQfK0X5twyL9HXNqgx2cykRWQY9f35KK u1EhoTGjv9+p99mi5668atSjVXeYJ2d04iD+actWBT76lUO0ObGaJ4/RNSTizVgIRMQL OkzQ==
X-Received: by 10.194.185.180 with SMTP id fd20mr15469621wjc.16.1437659966215; Thu, 23 Jul 2015 06:59:26 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ho10sm7667943wjb.39.2015.07.23.06.59.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 06:59:25 -0700 (PDT)
Message-ID: <55B0F344.4090005@gmail.com>
Date: Fri, 24 Jul 2015 01:59:32 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>
References: <alpine.DEB.2.02.1507230910190.11810@uplift.swm.pp.se> <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com>
In-Reply-To: <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/MW_u1i17sXAaicD_ykmiQdxQXTE>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 13:59:29 -0000

On 23/07/2015 22:30, Ted Lemon wrote:
> On Jul 23, 2015, at 3:42 AM, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
>> Read RFC 6147 - it covers this issue, and points out that
>> "The main drawback of this mode is its
>> deployability, since it requires changes in the end hosts."
> 
> I think Mikael is asking for a stronger statement than “you could do this, but probably won’t.”
> 
> I think this would take the form of a document describing recommendations for DNSSEC-aware stub resolvers, which I don’t think currently exists, and hence could in theory be worked on.

No, afaik it doesn't exist. I'm not certain that it needs to exist, though.
Would it specify anything that isn't already specified?

The code needs to exist.

   Brian