Re: [dnsext] A security concern regarding IPv6 support in name servers

Nicholas Weaver <> Mon, 20 September 2010 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBD1D3A69D7; Mon, 20 Sep 2010 06:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.254
X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NU8b81O9tS5v; Mon, 20 Sep 2010 06:09:09 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::62]) by (Postfix) with ESMTP id C6A343A6A63; Mon, 20 Sep 2010 06:09:07 -0700 (PDT)
Received: from majordom by with local (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1Oxg3F-0004yc-2B for; Mon, 20 Sep 2010 13:04:57 +0000
Received: from ([]) by with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1Oxg39-0004xv-CN for; Mon, 20 Sep 2010 13:04:51 +0000
Received: from ( []) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id BEAF13137D2; Mon, 20 Sep 2010 06:04:50 -0700 (PDT)
Subject: Re: [dnsext] A security concern regarding IPv6 support in name servers
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: Nicholas Weaver <>
In-Reply-To: <>
Date: Mon, 20 Sep 2010 06:05:03 -0700
Cc: Nicholas Weaver <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?iso-8859-1?Q?Alfred_H=CEnes?= <>
X-Mailer: Apple Mail (2.1081)
Precedence: bulk
List-ID: <>
List-Unsubscribe: To unsubscribe send a message to with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <>

On Sep 20, 2010, at 5:28 AM, Alfred HÎnes wrote:

> I have been pointed to a paper by H. D. Moore published in 2008,
> "Exploiting Tomorrow's Internet Today - Penetration Testing with IPv6",
> available at <>;.
> On page 3, this paper points out that Bind running on an IPv6-enabled
> system, unless its serving socket is bound to a specific IPv6 (unicast,
> interface-assigned) address of the system, also listens to multicast
> traffic (the memo apparently confuses the terms "broadcast" and
> "multicast") and will also respond to DNS queries received over IPv6
> multicast (e.g., to FF01::1).  This could be leveraged for discovering
> nodes and for various amplification / DoS attacks.

Except that if you are on the multicast domain of the victim, the victim is already screwed for reconnisance, because the other systems (eg, Macs, windows, etc) use multicast link-local and network-local IPv6 a lot for autoconfiguration.  

Just listening, let alone generating, traffic to the link local multicast will pretty much tell you everything in the network you might want to exploit.

ANd in fact the victim is just screwed because you can use ICMP6 router advertisements etc to direct the victim's internet traffic wherever you want to go.

Basically, if an attacker is within your IPv6 subnet (so link-local/site-local multicast works) you are totally lost.

And thus responding to requests on multicast is probably a Good Thing, as it enables inside-the-perimeter autoconfiguration and fallback, multicast-dns support, etc.