Re: [dnsext] duplicate RRs and resulting RRSIG

[Mohan Parthasarathy <[e-mail]>]

On Wed, Jan 4, 2012 at 12:26 PM, bert hubert <[e-mail]> wrote:
> Hi everybody,
>
> As part of a recent very big PowerDNS deployment as a DNSSEC signer,
> we've encountered an interesting issue. I'm sharing this here in hopes
> of hearing your wisdom, plus possibly to warn you about this happening
> in your code or deployments too.
>
> In a zone there are three MX RRs for a name, of which 2 are identical.
> PowerDNS signs all three records in canonical order when the zone is
> transferred to BIND (at least I think it is BIND).
>
> That server subsequently drops one of the two identical records, and
> serves only two MX RRs to the world, BUT with the RRSIG that was
> calculated from all three records. Bad data ensues, and bounced
> emails, since this is in the country that actually validates.
>
> Now, there are at least 3 places where we might call 'bug': 1) the
> process that put duplicate RRs in the database 2) PowerDNS for signing
> the 3 RRs or 3) the 'outer' server for silently dropping one of the
> RRs, in the assumption that the RRSIG will survice this process.
>
> RFC 2181, section 5, says that servers should (lower case) 'suppress'
> duplicate RRSIGs, which would argue that at least PowerDNS is
> partially to blame, and should've dropped the duplicate record.
> However, the outer server I think should also not feel free to drop
> records on an DNSSEC signed zone.
>
Section 6.3 of RFC 4034 states:

6.3.  Canonical RR Ordering within an RRset

   For the purposes of DNS security, RRs with the same owner name,
   class, and type are sorted by treating the RDATA portion of the
   canonical form of each RR as a left-justified unsigned octet sequence
   in which the absence of an octet sorts before a zero octet.

   [RFC2181] specifies that an RRset is not allowed to contain duplicate
   records (multiple RRs with the same owner name, class, type, and
   RDATA).  Therefore, if an implementation detects duplicate RRs when
   putting the RRset in canonical form, it MUST treat this as a protocol
   error.  If the implementation chooses to handle this protocol error
   in the spirit of the robustness principle (being liberal in what it
   accepts), it MUST remove all but one of the duplicate RR(s) for the
   purposes of calculating the canonical form of the RRset.

Going by this,  PowerDNS should have removed the duplicate RRs before signing.

-mohan

>
> What do you think?
>
>    Bert
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext