----- Original Message ----- From: "Paul Wouters" <p...@xelerance.com> To: "George Barwood" <george.barw...@blueyonder.co.uk> Cc: "IETF DNSOP WG" <dnsop@ietf.org> Sent: Monday, April 18, 2011 10:34 PM Subject: Re: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]
> On Mon, 18 Apr 2011, George Barwood wrote: > >> (1) It's my belief that almost all Zones except for the root zone should NOT >> use a KSK/ZSK split. >> With the signing of the root zone and many TLDs, manual distribution of >> trust anchors is likely >> to be uncommon. > > Not true. Any responsible organisation will configure their own zone's trust > anchoes in their > resolvers, so they can operate internally when their WAN/UPlink is down. Possibly. But I think this will be quite rare, and will only apply to organisations with very significant resources (maybe governments). I really doubt the significant extra complexity of managing these trust anchors is likely to lead to an overall increase in security. How are you going to distribute them? If you have a distribution mechanism ( other than the public one ) then you can presumably update the trust root config in a timely way when needed, so nothing is gained. >> (2) There is no point in using a larger key size than the smallest key size >> in the parent chain > > See 1) Those will benefit from additional strength that seems excessive to > any parent. I really doubt security would be improved in practical terms. The extra complexity of non-standard configuration would probably outweigh the minute benefit of longer keys, both in security terms, and even more certainly in terms of reliability. But anyway, yes, if you are really planning this, then a ZSK/KSK split might possibly be helpful, but not for typical domains. >> (3) Using a longer TTL for negative DS responses might be useful. Currently >> the negative TTL for >> the com zone is only 900 seconds (the SOA TTL). This is probably appropriate >> for a NameError >> (NxDomain) response, but 1 day might be more appropriate for a negative DS >> response, to improve >> caching performance and reduce load on servers. > > I think this issue should probably looked at in the light of the "child > centric" vs "parent centric" > issues we have seen. I don't know the right answer, but some others might > have better feedback on this. The DNSSEC standard seems vague (AFAICS) on the TTL of the negative DS information included with a referral from a secure to a non-secure zone (the SOA is not sent). I'm really not sure how it's meant to work ( this is possibly a bit off-topic here though - I asked a question in dnsext recently, no response yet ). > Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
