Re: [dnsext] Possible DNSSECbis clarifications

Mark Andrews <> Mon, 28 March 2011 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 461913A6A66 for <>; Mon, 28 Mar 2011 09:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EgrN576r2Da4 for <>; Mon, 28 Mar 2011 09:19:58 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:0:2::2b]) by (Postfix) with ESMTP id 29E273A6A61 for <>; Mon, 28 Mar 2011 09:19:58 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "", Issuer "ISC CA" (verified OK)) by (Postfix) with ESMTPS id 2789DC9423; Mon, 28 Mar 2011 16:21:33 +0000 (UTC) (envelope-from
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 7D63C216C22; Mon, 28 Mar 2011 16:21:32 +0000 (UTC) (envelope-from
Received: from (localhost []) by (Postfix) with ESMTP id 59CF9DA0471; Tue, 29 Mar 2011 03:21:20 +1100 (EST)
To: Marc Lampo <>
From: Mark Andrews <>
References: <> <00a701cbed28$64d1b1d0$2e751570$> <> <018401cbed48$0b8a6ac0$229f4040$> <> <01a901cbed53$e744b7e0$b5ce27a0$> <> <01b701cbed61$61cd3480$25679d80$>
In-reply-to: Your message of "Mon, 28 Mar 2011 17:55:36 +0200." <01b701cbed61$61cd3480$25679d80$>
Date: Tue, 29 Mar 2011 03:21:20 +1100
Message-Id: <>
Cc: 'Olafur Gudmundsson' <>,
Subject: Re: [dnsext] Possible DNSSECbis clarifications
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Mar 2011 16:20:08 -0000

In message <01b701cbed61$61cd3480$25679d80$>, "Marc Lampo" write
> A "theorical" attack would be a "man-in-the-middle" change the trailing
> SOA, thus causing the secondary server to throw away each zone transfer it
> attempts (if it "believes" the second SOA is correct, in the absence of a
> valid RRSIG for it - that trailing SOA).
> If a secondary name server is prevented from downloaded update of the true
> zone data, this is a security issue, I would say.

And we have solutions a solution to this.  It's called TSIG and has
been deployed for years with both signed and unsigned zones.

> It may not be that easy to set up this kind of attack, but then again,
> perhaps in some time somebody might show it can be done.
> My feeling is that, with DNSSEC, both SOA's in a zone transfer should be
> signed in a proper way (that they can  be validated) even if the SOA's
> differ.

DNSSEC as currently deployed cannot do this as RRSIG's are not
signed.  Early DNSSEC specs had the concept of a zone SIG.  This
covered the signatures.

> Which leaves us with another "hole" :
> Suppose potential attacker does indeed change trailing SOA, and fails to
> produce a validatable RRSIG, then what should the recipient do with the
> zone it downloaded ?  Since it can no longer verify if the content of the
> zone did not change, at the master, since the start of the zone transfer.
> Marc

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: