Subject: [dnsext] duplicate RRs and resulting RRSIG

From: bert hubert <[email-masked]>
Date: Wed, 4 Jan 2012 21:26:44 +0100

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.

What do you think?

    Bert

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 4 Jan 2012 12:39:04 -0800

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: [email-masked]
Date: Wed, 4 Jan 2012 20:54:14 +0000

> records on an DNSSEC signed zone.

RFC 2181 is DNSSEC oblivious.

What you are asserting is that prior to signing, you have two -identical- RRs... 
which accordingto RFC 2181, would be two identical RRsets (of a single RR each).
Once signed however, the RRsets are no longer identical, the NSEC RRs don't match,
so you have three unique RRsets.  (this may require a more careful reading of the
definition of an RRset....)

So the bug might be in PowerDNS allowing for identical RRsets when one should be
suppressed.  Once signed however, the RRsets are different and the external DNS
server is ignoring the RRset and extracting just some of the RRs and doing the 
evaluation...

/bill

---

From: bert hubert <[email-masked]>
Date: Wed, 4 Jan 2012 21:55:20 +0100

> Section 6.3 of RFC 4034 states:

Hi Mohan,

Thank you very much - and apologies for not searching through the relevant
RFCs!

>    RDATA).  Therefore, if an implementation detects duplicate RRs when

Well, it sorta says that. 

>    purposes of calculating the canonical form of the RRset.

This is exciting language - you MUST do A, but if you don't THEN you MUST do
B ;-) We'll go for B.

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

Very clear & will do!

	Bert

---

From: Doug Barton <[email-masked]>
Date: Wed, 04 Jan 2012 13:48:10 -0800

> This is exciting language - you MUST do A, but if you don't THEN you MUST do

It's not either/or. You MUST treat this as a protocol error (i.e., you
cannot let the data proceed in its current condition). The option is in
how you HANDLE the protocol error. You can either kick it back to the
user in terms of failing to load the zone, or you can fix it up
internally and proceed.

Personally, I think it's better to kick it back to the user. Otherwise,
how will they learn?

Doug

-- 

	You can observe a lot just by watching.	-- Yogi Berra

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: SM <[email-masked]>
Date: Wed, 04 Jan 2012 14:24:42 -0800

Hi Doug,
>Personally, I think it's better to kick it back to the user. Otherwise,

Other protocols handle such cases more gracefully ( 
http://www.imc.org/ietf-smtp/mail-archive/msg06633.html ). :-)

Regards,
-sm

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Fri, 6 Jan 2012 09:05:00 +0100

Hi Bert,

> records on an DNSSEC signed zone.

What about RFC4034, section 6.3:

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

--
Marco

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Jan 2012 18:25:53 +0000

bert hubert <[email-masked]> wrote:
> duplicate RRSIGs

Note that RFC 2181 predates widespread use of MUSTard.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: Southwesterly veering westerly 5 to 7, occasionally gale 8
later. Moderate rough, becoming rough or very rough, occasionally high in
north Forties later. Rain then squally showers. Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Jan 2012 18:29:47 +0000

> which accordingto RFC 2181, would be two identical RRsets (of a single RR each).

You have misunderstood RFC 2181's definition of RRset. Identical RRs have
the same owner, type, and class, so are part of the same RRset.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: Southwesterly veering westerly 5 to 7, occasionally
gale 8 later. Moderate rough, becoming rough or very rough, occasionally
high in north Forties later. Rain then squally showers. Moderate or good.