Re: [v6ops] NAT64/DNS64 and DNSSEC

Philip Homburg <> Wed, 29 July 2015 10:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1671C1A1A33 for <>; Wed, 29 Jul 2015 03:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YLIh_z4D1yUX for <>; Wed, 29 Jul 2015 03:26:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C53BD1A0211 for <>; Wed, 29 Jul 2015 03:26:48 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (Smail #91) id m1ZKOZT-0000CeC; Wed, 29 Jul 2015 12:26:47 +0200
Message-Id: <>
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Wed, 29 Jul 2015 12:06:14 +0200 ." <>
Date: Wed, 29 Jul 2015 12:26:47 +0200
Archived-At: <>
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jul 2015 10:26:51 -0000

In your letter dated Wed, 29 Jul 2015 12:06:14 +0200 you wrote:
>That is why there is a requirement in RFC7050 Section 3.1. to validate
>network-specific NAT64 prefix using reverse and forward DNSSEC secured
>queries. The only problem is that there is no way so far how to seed the
>list of trusted NSP domains. Instead of asking users "Do you want to
>trust the network prefix", there could probably be
>some matching with domain name received by other means like DHCP or DNSSL=
>Of course, using the Well-known prefix is on the safe side, and should
>be IMO used wherever applicable.

It seems to me that Section 3.1 is very far from something can be implemented
in a practical way in a consumer device.

I.e. if a user with a mobile device connects to a random network that employs
NAT64, there is essentially no way for an ordinary user to verify if the
prefix is valid or not.

Now if there would be DHCPv6 and RA options for the prefix, there would be
no need to discover the prefix using the DNS64 resolver and the problem would
reduce to whether to trust DHCPv6 or RA. Which is already part of the
security model (i.e. RA guard can protect users from each other).