Re: [dnsext] Possible DNSSECbis clarifications

"Marc Lampo" <> Mon, 28 March 2011 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C610D3A6870 for <>; Mon, 28 Mar 2011 08:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xFTIknbhntKt for <>; Mon, 28 Mar 2011 08:59:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC76728C0CF for <>; Mon, 28 Mar 2011 08:59:22 -0700 (PDT)
X-ASG-Debug-ID: 1301328059-5cfc55220001-uIE7UK
Received: from ( []) by with ESMTP id WsxUGnPIyOECSA38; Mon, 28 Mar 2011 18:00:59 +0200 (CEST)
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id D8482E406A; Mon, 28 Mar 2011 17:55:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2JChYb6oQzSo; Mon, 28 Mar 2011 17:55:36 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id C4B38E4053; Mon, 28 Mar 2011 17:55:36 +0200 (CEST)
From: Marc Lampo <>
To: 'Joe Abley' <>
References: <> <00a701cbed28$64d1b1d0$2e751570$> <> <018401cbed48$0b8a6ac0$229f4040$> <> <01a901cbed53$e744b7e0$b5ce27a0$> <>
In-Reply-To: <>
Date: Mon, 28 Mar 2011 17:55:36 +0200
X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications
Message-ID: <01b701cbed61$61cd3480$25679d80$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AcvtWwh2O+iF8A7nSbOhfw6FrDnD9QABWJnQ
Content-Language: en-za
X-Originating-IP: []
X-Barracuda-Start-Time: 1301328059
X-Virus-Scanned: by bsmtpd at
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 15:59:23 -0000

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.

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

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.


-----Original Message-----
From: Joe Abley [] 
Sent: 28 March 2011 05:21 PM
To: Marc Lampo
Cc:; 'Olafur Gudmundsson'
Subject: Re: [dnsext] Possible DNSSECbis clarifications

On 2011-03-28, at 16:19, Marc Lampo wrote:

> But then, how to link a RRSIG(SOA) with *its* SOA ?

If there are multiple, different SOAs found in an AXFR response then you
throw that response away. RFC 1034 seems fairly clear on that.

  When the poll shows that the zone has changed, then the secondary server
  must request a zone transfer via an AXFR request for the zone.  The AXFR
  may cause an error, such as refused, but normally is answered by a
  sequence of response messages.  The first and last messages must contain
  the data for the top authoritative node of the zone.  Intermediate
  messages carry all of the other RRs from the zone, including both
  authoritative and non-authoritative RRs.  The stream of messages allows
  the secondary to construct a copy of the zone.  Because accuracy is
  essential, TCP or some other reliable protocol must be used for AXFR

> Or simply : "try" all available RRSIG(SOA)'s, if at least one validates
> the SOA being looked at, then accept it.

Zero or one RRSIG RRSets over the SOA, one SOA RR and one identical copy
of the same SOA record. I don't see a validation problem.