an alternative to K* files

Jim Reid jim at rfc1035.com
Thu Feb 11 14:50:30 UTC 2010


I agree wholeheartedly with Johan. It would be be nice if there was  
something better than these K*.{private,key} files. They are rather  
clunky and won't work for very long domain names: the prefix and  
suffix cruft will make the resulting file name bigger than the OS will  
allow. [IIRC POSIX says file names can't be longer than 255  
characters.] It's also easy to confuse KSKs with ZSKs, so a clearer  
naming convention for the key files would reduce those sorts of  
mistakes. I think too that the intelligence about identifying the  
right key(s) belongs in the signing tools and file contents/ It  
shouldn't need hints embedded in the file names.

So, how about zsk.{private,public} and ksk.{private,public} files?  
These could have all the keys needed for all the zones held on the  
server, say in the name server's default directory. Or there could be  
zone-specific ones to over-ride that default. Something like:

	zone "foo" {
		type master;
		...
		key-directory "bar";
		zsk-file "not-the-default-one";
		ksk-file "local-choice";
	}

These hypothetical files would need to be structured in some way so  
that the keys could be tagged. Which may be no bad thing. It would be  
good to have human readable meta information to assist with key  
management and general server administration: ie This is a 2048-bit  
RSA-SHA256 ZSK for domain foo which was generated by bar using foobar  
on <date> and will be withdrawn on <date>. Its key id is <tag>. Use  
that tag whenever the key needs to be manipulated with the management  
and signing tools.



More information about the bind-workers mailing list