Re: [dnsext] Possible DNSSECbis clarifications

["Marc Lampo" <[e-mail]>]

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
differ.

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

-----Original Message-----
From: Joe Abley [mailto:[e-mail]] 
Sent: 28 March 2011 05:21 PM
To: Marc Lampo
Cc: [e-mail]; '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
  requests.

> 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.


Joe