IETF Logo Mail Archive

[v6ops] NAT64/DNS64 and DNSSEC

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 23 July 2015 07:17 UTC

Return-Path: <swmike@swm.pp.se>
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 9E9611ACAD8 for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 00:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zjpGPT3X1y_G for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 00:16:59 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1491B2A1C for <v6ops@ietf.org>; Thu, 23 Jul 2015 00:13:27 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63572A1; Thu, 23 Jul 2015 09:13:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437635606; bh=Zu4ljlfSSdACx0mD5JZCtRZ3PNn3qc5MJLiS4dQqQTU=; h=Date:From:To:Subject:From; b=Rl9yj2xn57iIZyxF1nJ0mhxtcuwoSlCqj48QYmBoOSYocNZGHh8H3ttcQFLq2XEgP Kbc/1ZDbO9bXEb7n+GhnpiD3cMeB+GIZPnDslfz3rbtFxnxfnMDAPSGrrsoF/8eGrL Wh9r+EYZO/ee38T5FkW6seYGlwR/hB+pk2wcqUXk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5895C9F for <v6ops@ietf.org>; Thu, 23 Jul 2015 09:13:26 +0200 (CEST)
Date: Thu, 23 Jul 2015 09:13:26 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: v6ops@ietf.org
Message-ID: <alpine.DEB.2.02.1507230910190.11810@uplift.swm.pp.se>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/tj_uUAQ2yIeJPtwfmsMgi00bVMI>
Subject: [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 07:17:01 -0000

Hi,

as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because 
modifying A records into AAAA records breaks DNSSEC.

Since we now have implementations (from what I understand at least APple 
does this) that do bump-in-the-API, would it make sense to work on a 
document that recommends to just use DNS64 just to discover the NAT64 
prefix, and then do bump-in-the-API synthesis to do the A-to-AAAA 
NAT64-mapping?

I really care about DNSSEC and I don't want this to be broken for a 
prolonged amount of time just because people are doing NAT64+DNS64.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email