Re: [v6ops] NAT64/DNS64 and DNSSEC

Philip Homburg <> Tue, 28 July 2015 21:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B95C51B31A1 for <>; Tue, 28 Jul 2015 14:44:56 -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 0VEgjpDSeSr4 for <>; Tue, 28 Jul 2015 14:44:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 560011B2AB8 for <>; Tue, 28 Jul 2015 14:44:52 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (Smail #91) id m1ZKCg7-0000CdC; Tue, 28 Jul 2015 23:44:51 +0200
Message-Id: <>
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Tue, 28 Jul 2015 21:58:12 +0200 ." <>
Date: Tue, 28 Jul 2015 23:44:51 +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: Tue, 28 Jul 2015 21:44:56 -0000

In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote:
> but isn't there a gap that when performing the RFC7050 64pref
> detection by querying, an attacker can spoof this
> answer (DNSSEC won't work here, for example, the attacker - when
> between the client and the DNS - can return for example
> 2001:db8:: (where 2001:db8:: is a prefix owned by the
> attacker)) and then attract all IPv4 traffic from the victim?
> Nevertheless, an answer to the proliferation of DNSSEC and at the
> same time increasing usage of DNS64/NAT has to be found, not to
> stop the success of one or the other.

Yes, that seems to be a very tricky problem.

One option is perform local translation only for 64:ff9b::/96. This would
force operators to use the well known prefix, but it has to advantage that
the prefix can be filtered at the border of each network. And an attacker
will be quite visible trying to get this traffic by manipulating routing

A second approach is for the network to signal that there is no IPv4 present.
For example, by not including a default route in DHCPv4 or otherwise signaling
in DHCPv4 that there is no IPv4.

In this case, if there is a valid IPv4 config, the library can refuse to
perform the synthesis. This would leave all dual stack networks unaffected.

Performing the AAAA lookup on over tcp would require
the attacker to be on the path to the resolver.

An alternative to requiring 64:ff9b::/96, would be to insist that the
NAT64 gateway and the DNS64 are in the same /48. That would require an
attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets
are off.

Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious
solution is that if those sites care about security, they should add a AAAA.