On Mon, Nov 09, 2015 at 04:53:34AM +0000, Viktor Dukhovni wrote:
> I still think this should support and use DNS compression.
>
> Each RRset in the chain is composed of a sequence of wire format DNS
> resource records. The format of the resource record is described in
> RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be
> presented in the canonical form and ordering as described in RFC 4034
> [RFC4034].
>
> RRs within the RRset are ordered canonically, by treating the RDATA
> portion of each RR as a left-justified unsigned octet sequence in
> which the absence of an octet sorts before a zero octet.
>
> Here, I'd like to lift both the restriction on the order and
> canonical form. In which case, the server can return the
> records in exactly the form it obtained them from its own DNS
> server, likely not canonically ordered, and quite possibly with
> compression!
An alternative, (given that the server is expected to cache the
extension and the server-side processing cost is presumably ammortized
over multiple requests) is to collapse all the relevant RRsets into
a single ("recompressed" by the server) DNS packet in which the
initial TLSA RRset (preceded by any CNAME/DNAME and related RRSIG
records that lead to this RRset) and its RRSIG appear in the "answer"
section, while all the other records, (relevant RRSIG, DNSKEY and
DS records of parent zones) are in the "additional" section.
This single DNS "jumbo" packet can be picked apart and processed
by a suitable DNS library that has existing code to process DNS
packets with multiple RRsets (in multiple sections), in this case,
as though the reply came from a root server, so that all the
additional records are "in bailiwick".
Of course the library might still need new code to support DANE
processing in this new way, but there's a chance it might "just
work", if all the RRsets are imported before any are verified.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
