IETF Logo Mail Archive

Re: [v6ops] NAT64/DNS64 and DNSSEC

Philip Homburg <pch-v6ops-3@u-1.phicoh.com> Fri, 24 July 2015 11:07 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.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 CB0D41A88CB for <v6ops@ietfa.amsl.com>; Fri, 24 Jul 2015 04:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.6
X-Spam-Level:
X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 KX5PNntBCSSs for <v6ops@ietfa.amsl.com>; Fri, 24 Jul 2015 04:07:56 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 19FA91A8F4E for <v6ops@ietf.org>; Fri, 24 Jul 2015 04:07:56 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZIapX-0000CgC; Fri, 24 Jul 2015 13:07:55 +0200
Message-Id: <m1ZIapX-0000CgC@stereo.hq.phicoh.net>
To: "v6ops@ietf.org" <v6ops@ietf.org>
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <alpine.DEB.2.02.1507230910190.11810@uplift.swm.pp.se> <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <ED7E283A-0430-4D4E-87A6-ED9FD8DFC6F4@nominum.com> <m1ZIYIw-0000EuC@stereo.hq.phicoh.net> <CAAedzxrWExsiyh4hhsfJTufuRVM_67f2tGWkHCLc9kiduTU0hg@mail.gmail.com>
In-reply-to: Your message of "Fri, 24 Jul 2015 12:37:05 +0200 ." <CAAedzxrWExsiyh4hhsfJTufuRVM_67f2tGWkHCLc9kiduTU0hg@mail.gmail.com>
Date: Fri, 24 Jul 2015 13:07:54 +0200
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/g_xDzH8pjV9VJC8ezVxTEczhdmE>
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: Fri, 24 Jul 2015 11:07:58 -0000

In your letter dated Fri, 24 Jul 2015 12:37:05 +0200 you wrote:
>> I guess this is easy enough to add to for example getdns
>> (https://getdnsapi.net/). One question is how an application would find out
>> that it is running in a DNS64 environment. Another option is for getdns to
>> do the probing and enable this option automatically.
>
>One approach comes to ming: when a client resolver starts up, it
>checks ipv4only.arpa
>(https://tools.ietf.org/html/rfc7050#section-8.2), and after that can
>synthesize AAAAs as needed (DNS64 in done in the client) while getting
>validated answers for other things as desired.

I was wondering whether this should be done by the application or be part of
the library.

If it is documented somewhere as a thing to do for local DNSSEC validating 
libraries then we can treat NAT64/DNS64 as completely transparent to the
application.

But there might be reasons why applications don't want this to happen.

v2.23.0 | Report a Bug | By Email