Limiting the Scope of the KEY Resource Record
Dan Massey, Scott Rose
Atlanta GA

KEY RR Restriction
KEY RR now restricted to DNSSEC protocol only
No Subtyping of KEY RR
All other protocols (IPSEC, email, etc.) obsolete and must not be used to store key material
All flags bits, except one, now obsolete
“zone key” bit (bit 7 – backwards compatibility)
Avoid large keysets, especially at apex
Avoid subtypes of KEY RR
Including using SRV-like naming scheme
Separate administration of DNSSEC and Application keys

Status of Draft and DNSSEC
In RFC Editor’s Queue
No RFC number yet.
New version of DNS Security Specs in WG
Focus on DNS only
Not mentioning other applications/key distribution as a service of DNSSEC
Not forbidding the storing of application key material in DNS either.

Lessons Learned from DNS KEY RR (Or:  Minefield Ahead!)
Pitfalls to avoid when creating a new RR type to store application key material
Avoid Subtypes
Don’t assume DNSSEC is the right trust model
Define and Justify why DNS and/or DNSSEC makes sense to use in an already existing trust model.
Clearly state impact on the DNS
Should be “minimal” (i.e. Just a data RR like TXT)
Anything requiring a change will probably be a problem.
Good idea to include someone with DNS experience to consult on these issues.