Changes

* A DS The DNSKEY (and corresponding RRSIG) record records for a zone to enter, in wire format. There must be a key signing key present.* The DNSKEY A DS (and corresponding RRSIG) records record for that zonethe key signing key in the previous record, in wire format. The This DS must correspond be from a zone outer to one that of the keys. The following set of keys must be from the same zone as this DS record.

Each zone entered must be directly inner to the previous zone. The root zone may be omitted, because it is assumed that the client already has the DNSSEC keys for the root. The final entry is a TLSA (and corresponding RRSIG) record, again in wire formatis prefixed to the chain and must be from the same zone as the first key set.

* The TLSA (+RRSIG) for foo.bar.com* The DNSKEYS (+RRSIGs) for bar.com* The DS (+RRSIG) entering for bar.com (from .com)

* The DS (+RRSIG) entering bar.com* The DNSKEYS (+RRSIGs) for bar.com* The TLSA (+RRSIG) for foofrom .bar.com (given that the bar.com is authoritative for foo.bar.com)

It is possible to optimize away some fields of these records, but at the moment this is not being done. Another optimization would be for the client to indicate a root of trust deeper down the tree so that the server can omit some zones. For example, a client may already have (and have validated) all of the keys for .com. In the above example, if the client has already validated keys for .com, the server need only send the DS TLSA record entering , the keys for bar.com , and the keys for DS record entering bar.com (as well as the final TLSA recordsignatures, of course).

For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-01 here]. Note that this proposal does not follow exactly the wire format of DNS records. Additionally, it reverses the order of records. Consequently, preexisting code cannot be used to serialize, parse, or validate the chain. Additionally, more flexibility means more opportunities for insecure verifier behavior. This proposal is not currently being used in this project.