Hi Nathan On 7/04/2011, at 9:56 AM, Nathan Ward wrote:
This is the second time you've come out with this attitude in this thread, and I for one don't appreciate it. This is a public discussion list, and while you are asking the question, many are reading the answer. I know and understand all of the above as well, but have found it valuable as it challenges some default assumptions people have about how to do this stuff. If this were some kind of business support line, I'd understand your response and lack of desire to be patronised, however that's not the case and on a public list you're going to get answers with more information than you need. If you want to consider that patronising that's fine - I'm sure the rest of us will be thankful to Joe for taking his time to present a whole lot of information and a different potential approach. (I know I do this as well sometimes as I'm sure many others do too, but, hopefully significantly less blatantly)
I'm sure we all see the value in comments that are general information that we all benefit from, but there is a big difference between that and telling someone how to do their job. The following para fell very clearly into that latter category:
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
While that para is certainly of interest to many people, it is specifically telling a TLD operator not to worry about performance of signers because of the specific characteristics of a TLD zone and how they might reduce the performance burden. Asking whether those points had been considered would be reasonable and polite, but a lecture is patronising.
Is anyone aware of DNSSEC software (OpenDNSSEC, what else is there?) being rolled in to Linux distros etc.? What about those control panel things that manage DNS for you (I think cPanel is one)?
What is expected when DNS is hosted by a third party - someone like iServe that have a DNS management web interface etc.? Will they hold all the keys for the zone? Will the encryption for these keys require a password from the customer each time? Amazon EC2 does an interesting thing where you create a Windows VM and then ask it for the Admin password - you get shown encrypted data and a box in which to post your private key, and then there is what I believe is a Javascript routine that does the crypto operation to decrypt the password on the client side. Perhaps some kind of client-side signing operation similar to this makes sense? I doubt it'd be terribly practical, but maybe it's worth exploring.
The main products that support DNSSEC come into two types: - open source apps that you can integrate into your own signing process - BIND, OpenDNSSEC are two. - commercial appliances that are either "bump in the wire" boxes or full service platforms - Secure64 and Infoblox are two. I'll try to dig out some links to resource sites where this sort of information is being aggregated. cheers Jay
"DNSSEC Deployment Scenarios" sounds like an interesting NZNOG talk. (I'm hoping it hasn't already been done while I was having a uh meeting)
-- Nathan Ward
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840