Server returns complete RR set?

[MelindaShore]

From Viktor:

" I'm not sure what purpose the last paragraph of section 3 is
intended to serve:

Obviously, an authentication chain will be most compact and easiest
to verify if each RRset has a single record, i.e., if there is a
single DNSKEY RR and a single DS RR at each step. In addition, as
suggested above, keeping zone cuts to a minimum also reduces the
length of the authentication chain.

The TLS server has no choice but to return the complete RRset for
each owner name class and RRtype, since RRSIGs cover RRsets, not
individual RRs. So "compacting" is possible. The server returns
the RRsets exactly as published by the relevant DNS(SEC) servers.

Speaking of RRsets, are the RRs in each RRset returned by the server
required to be sorted in canonical order"

[MelindaShore]

Related, he also says:

"The draft often says "TLSA record" when it needs to say "TLSA
RRset". It will be quite common for multiple TLSA RRs to be present
in the RRset, as this is required to correctly effect key rotation.
Therefore, in Section 6 (and elsewhere), text such as the below:

If the record is correctly authenticated, the client then performs
DANE authentication according to the DANE TLS protocol [RFC6698].

is sub-optimal, it should refer to a TLSA RRset, which MUST contain
at least one TLSA record that matches the server's certificate
chain, but will often contain additional records that do not."

[shuque]

Yes, Victor is correct. On the first point, DNS RRsets are returned atomically as a unit, and RRSIG signatures are computed over the entire RRset, so single or partial records from an RRset cannot be returned.

On the second point, RRs in an RRset do not need to returned in canonical order, as long as the verifier (client) sorts them canonically before signature computation. If the server does always return them in canonical order, then it will be less work for the client. But for implementers using DNS libraries, it will be easiest to produce and consume whatever order the libraries return and let them do the right thing. So it might be best to leave this unspecified.

On the third point, yes, the draft should mention RR sets rather than records where the former is correct.

I will send in some adjusted text for the 1st and 3rd points.

[shuque]

I believe there is one (slightly different) optimization we're planning to do involving only one RRSIG per RRSET. Some new text would be needed to describe that if so.