> On 22 Feb 2019, at 8:02 am, Ted Lemon <[email protected]> wrote: > > On Feb 21, 2019, at 11:24 AM, Mark Andrews <[email protected]> wrote: >> Ted. It has to work post zone transfer. > > That’s not a problem, since the representation would be more compact, but > would not be lossy: the interchange through the zone transfer would be the > same regardless of how the data is stored.
Implementation details are beyond the scope of RFCs. Also you mentioned caches which basically will never see these records unless they are queried for. Yes, there is a minuscule probability of a hash collision. The alternative is to define a type for rdlen + rdata in canonical DNSSEC form. The primary server can use/replace a hash when the rdata + length is longer than the hash, checking for collisions first. If such a type is defined I would give it the value 1 and make the first actual hash 2. Additionally in section 4.5 Cryptographic Hashes "Any names contained in a resource record MUST be hashed in an uncompressed form." needs to be replaced with "The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)." The latter works with primary servers that don’t preserve case when transferring zones. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
