Subject: Re: Q19: supression of duplicate RRs in an RRset

From: David Blacka <[email-masked]>
Date: Tue, 4 Nov 2003 16:02:22 -0500

On Tuesday 04 November 2003 02:37 pm, Scott Rose wrote:
> This is (probably) another non-issue, but for procedural completeness:
> 
> Q19:  Should multiple instances of identical RRs in an RRset be reduced 
to a
> single RR during the signing process?

Yes.  Signatures obviously don't work if what is signed isn't what is 
served.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Nov 2003 21:39:06 +0000

> Q19:  Should multiple instances of identical RRs in an RRset be reduced to a

arguably not.  these should be removed during the process of reading/loading/
importing the zone, and so the signer should never see them, nor should axfr
be able to transfer them, or query be able to return them.

this is how bind8 and bind9 work in the case shown below:

> Consider the zone file:
> 
> a.example.com    IN    A    1.2.3.4
> a.example.com    IN    A    4.3.2.1
> b.example.com    IN    A    1.2.3.5
> ...
> a.example.com    IN    A    1.2.3.4

duplicate rdata is just too hard to think about.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 4 Nov 2003 18:50:01 -0500 (EST)

> Q19:  Should multiple instances of identical RRs in an RRset be
> reduced to a single RR during the signing process?

Absolutely.  See the discussion about ambiguous formats in the large
typecode thread.

-- Sam

---

From: Rob Austein <[email-masked]>
Date: Tue, 04 Nov 2003 20:11:46 -0500

> be able to transfer them, or query be able to return them.

But if for some reason a zone signer were somehow to see such
duplicates, said zone signer should generate signatures based on the
RRset with the duplicates removed.  Right?

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Nov 2003 08:51:26 -0500

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 04, 2003 4:39 PM
Subject: Re: Q19: supression of duplicate RRs in an RRset

to a
> be able to transfer them, or query be able to return them.

The signature generataion process could be seperate from the zone
loading/serving process.  A duplicate RR in a set may slip through the
signer, then be caught by a name server during reading.  By then, it is too
late, the RRSIG is incorrect and will not be verified by a resolver.

The idea that it should not be silently ignored is probably better.  That is
another option to state/replace in the drafts.

Scott

---

From: Roy Arends <[email-masked]>
Date: Wed, 5 Nov 2003 09:44:12 +0100 (CET)

> be able to transfer them, or query be able to return them.

Lets do worst case, and go with robustness principle.

Disambiguate the RRset for cryptographic processing _only_.  The
disambiguation algorithm is documented, and has no bearing on whatever
format the RRset itself leaves or arrives on the wire.

Duplicate records in a RRset are legal and used for (imaginary) load
balancing purposes (yes, I don't like it either).

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 9 Nov 2003 20:19:43 -0500 (EST)

> format the RRset itself leaves or arrives on the wire.

You mean by suppressing duplicates, right?

> balancing purposes (yes, I don't like it either).

RFC2181 (proposed standard), Section 5: "It is meaningless for two
records to ever have label, class, type and data all equal - servers
should suppress such duplicates if encountered."

Since a 2181 compliant server should [1] suppress duplicates, it would
be foolish to assume than duplicates will reliably reach a validator.

If we want to change that and come up with a disambiguation scheme
that accomodates duplicates, then we need something other than
2181-compliant servers transporting the data.

In other words, we should give up now.

-- Sam

[1]  2181, section 3:
   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
   their negative forms.  In some sections it may seem that a
   specification is worded mildly, and hence some may infer that the
   specification is optional.  That is not correct.  Anywhere that this
   memo suggests that some action should be carried out, or must be
   carried out, or that some behaviour is acceptable, or not, that is to
   be considered as a fundamental aspect of this specification,
   regardless of the specific words used.  If some behaviour or action
   is truly optional, that will be clearly specified by the text.

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Nov 2003 05:18:43 +0100 (CET)

> You mean by suppressing duplicates, right?

Yep, for crypto purposes only. It is okay to have dupes on the wire or in
presentation format.

> be foolish to assume than duplicates will reliably reach a validator.

Not at all. There might be implementations written by folk who interpret
"should" less stringent as others.

> In other words, we should give up now.

Sure. We agree. Disambigation text (canonical form for RRsets) needs to
include text on surpressing dupes.

Lets not put any restrictions on the wire and presentation format.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:05:17 +0000

> ...
> off topic for Q21 (re: dnssec rrs):
> In a way, yes.  NSEC RRs could be queried for the information they do
> contain, since they contain more non-security information than RRSIGs.  I
> can imagine a scenario where a application may want to issue NSEC queries
> instead of "name.  IN  ANY"  queries, for example.  An RRSIG isn't that
> informative without the RR set it covers.  A NSEC RR contains some
> information that could be used in a non-DNSSEC manner.

let me emphasize what i mean by metadata.  i'd like to see NSEC, RRSIG,
and DNSKEY treated more like AXFR and IXFR, such that one could never
query for them directly.  their only existence should be as part of zone
transfers or responses containing signed data.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Nov 2003 10:15:19 +0100

Q19: Suppression of duplications

      This issue is about the canonicalization process by the signer and
      the verifier.

      Duplicates are specifically forbidden. On the list there have been
      several oposite opinions with regards to how to deal with this issue.

      We propose the following text as consensus position:

      Duplicate RR records are not allowed exist according to
      [RFC2181]. Implementations MUST therefore treat duplicate RR
      records as protocol errors. Signers and verifiers MUST
      canonicalize duplicate RR sets by removing duplicate RRs from
      the set if the implementation is designed to be liberal in
      handling protocol errors.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

-- Olaf
   DNSEXT co-chair

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC